Aisha Blake, talks to Developer Advocate at New Relic, Nočnica Fee, about how the technical field is a 50/50 split between people writing code and people doing a thing often overlooked: operations, and in order to learn a skill, you first have to understand all the individual components of that skill. You should always have some tangible goal you're trying to get to, and changing strategies to get there along the way is a-okay!

Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!

Give us a follow: @PolyglotShow

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Aisha Blake: Hello and welcome back to Polyglot. I'm your host today. I'm Aisha Blake, and I am Lead Developer Relations Engineer at New Relic. I'm really, really excited today to talk with my guest, Nočnica Fee.

Nočnica Fee: Hey, everybody. This is Nočnica. I do developer relations also for New Relic. You might know me from the live streaming shows at Nerdlog where we talk about product updates or the uptime where I talk about product updates, but it looks certainly better because it's pre-recorded. It’s every month.

Aisha: [laughs]

Nočnica: I do a lot of live streaming stuff, do conference talks, do all kinds of fun things. And I'm excited to come on today. We were hoping...we were talking about topics. We're like, what are we going to talk about?

Aisha: Yeah. And I feel like, with you, there are so many options.

Nočnica: So back in the day...you can find me everywhere as ServerlessMom. But these days, serverless is not necessarily my big focus. So we have a lot of stuff we got to talk about, like cloud engineering stuff.

Aisha: I'm excited. Certainly, I've learned a lot in my time at New Relic, but that's not my home. And so I think I love the idea of starting kind of talking about what your path has looked like. And maybe we'll branch off from different parts of your own journey and go from there. And I'll have lots of questions for you.

Nočnica: What you see, right? You see, people talk about as a sort of placeholder for talking about working as a job in technology is they say, "Oh, well, I don't want to learn to code," or "I have to learn to code if I'm going to go do this job. If I'm ever going to stop sleeping in my parent’s basement, I have to learn to code," because the economic system has continued to grind people down.

I often say when people are depressed about how they are with money, they're bummed. They're just, "Oh, I buy too much delivery food or something." I always say remember that in your parents' generation, people who were bartenders bought houses. So obviously, we want to have financial security, and we'll want to try for it. But don't forget that the system isn't really in your favor like it used to be. I don't know, take it with a grain of salt, but it's true. So making it what you will.

So we often say, "Hey, just learn to code," and that's a standard. But even when people are pretty serious about they want to have a job in technology, they're very often being told, "Hey, go learn HTML and CSS and stuff and use that as a pathway into software and web development."

Aisha: Absolutely

Nočnica: And you occasionally hear, "Oh, I'll work in maybe...or I'll do something related to cryptocurrency." That's the big one right now. But all of these other jobs that exist in software really don't come onto people's radars. And part of that is the soft skills stuff like I do where it's like, oh, there's developer relations, and marketing, and growth marketing, and sales, all these things that are like ancillary jobs to the technical field. But the other thing is that the technical field is about 50/50 split between people writing code and people doing this other thing that no one talks about called operations.

Aisha: Yeah. And I think that that is true of so many people's entry into the industry as a whole. You have a handful of very, very visible options. And so that's what you gravitate towards most of the time. Very rarely have I had someone come up to me and say, "I am really interested in operations. I've heard about it. I don't really know what it is." Usually, if somebody has a more specific path in mind, it's because they know somebody, and they've seen them doing this thing. And they're like, that sounds like it could be right for me.

Nočnica: Yeah, there's a pretty common pattern that's like they got a very entry-level job working on a help desk. And then they did some administrator stuff with the UI, then they got asked to do some administrator stuff with the command line, and they're moving into it. Often when you're working on that help desk, you're working next to the person who's sitting there sweating in the server room. And so you often have that sort of guide.

So you don't get someone just walking and saying, "Hey, I want to become a Linux administrator, and I'm just doing that based on Google searches. And how do we get started?" Usually, they're saying, "Hey, I'm trying to learn Python," or "I'm trying to learn this other language." It was interesting for us, I think, at New Relic, we often are guilty of when we want to talk to people who are starting out; we kind of do the same thing. Like, hey, let's come and teach you Python.

Even though New Relic is a production monitoring tool, somebody who writes Python all day probably doesn't care how their code runs in production. That's really not their job. The job is to make new features, not to keep track of is the memory running out on our main servers or is the code performing well in production? So okay. So let's talk about it. Let's talk about that getting started. Because one of the things...Lord, forgive me for the things I'm about to say, but I've been spending more time on reddit.com. So I'm sorry.

Aisha: [laughs]

Nočnica: If my family and loved ones can hear me saying this, I'm sorry. I know I said I quit. I know I said I would stop. But you can't. Oh, you just can't. It just keeps dragging me back.

And the question I see quite a bit is like, "Hey, I'm trying to get started with Kubernetes." This is like, "Hey, I bought a laptop. And I've searched for tutorials, and I'm trying to get started with Kubernetes." And that is not going to work. And I would encourage somebody to do anything that their little heart desires. When you want to do machine learning right out of the gate, great. These are practical engineering challenges. Anyone can get started doing them. Obviously, it will take you a long time to get a lot of knowledge in a really obtuse area.

But saying, "Oh, I want to get started with Kubernetes," I try to think of the analogy...I can't think of a perfect one. It's sort of like someone saying, "Hey, there's an industry where you repair cars, and I want to get started by altering the fuel mixture in whole fleets of cars," where it's like, "Well, do you know how a carburetor works?" Like, "No." "Do you know how a fuel system works?" "No." That's not going to work, right?

Aisha: Yeah.

Nočnica: Orchestration is one of these things that exists in the world of software and actually not that applicable in the real world necessarily, but there's just, I mean, I suppose one way to think about...I'm just thinking about the literal definition is orchestration is like you cannot say, "Hey, I'm interested in music, and so what I want to do is try to be a conductor."

Aisha: That's exactly the analogy I was thinking of. Like, if you don't understand music theory...

Nočnica: Yeah, I got a little baton, and I started waving it at crowds of people, and they're not playing any Sousa at all. [laughter] That's actually a way better analogy because we don't expect that a conductor is the best oboist or even a concert oboist. But obviously, they must understand a great deal about the individual components. So I was thinking we could take a minute and talk about how someone could get to that point because I can't teach you everything in a half-hour podcast, or I don't know how long this thing is supposed to be; 45 minutes?

Aisha: [laughs]

Nočnica: But there is a curriculum that you can follow that sort of says, hey, here are the skills I want to check off, and here's where I want to be next, and Kubernetes is on there. It's just it’s one that there are two or three other foundational skills before you can get started.

Aisha: Absolutely, let's do it.

Nočnica: Let's jump in feet first. So if someone asked me...I tried to make some notes and sort of say, you know, this isn't something authoritative. And there may be better versions of any one of these resources. I'm sure we'll link to these in the show notes as well.

Aisha: Definitely.

Nočnica: So the main thing is if we go with that conductor musician analogy, is you have to understand the individual components of any kind of cluster, which means you have to understand a Linux machine. So until you get up to the Kubernetes level, you really shouldn't have to spend any money at all except maybe to buy a book or if you have no working PC to get a working PC.

But I think a really good first goal is to run a Linux machine generally as a virtual machine or on a Raspberry Pi and one without a UI. So just from the command line, you should be able to control it. And that feels pretty daunting to start with. You're just looking at this little text prompt blinking and saying, "Hey, what do I put in here?"

Aisha: I'm yours to command.

Nočnica: Yeah. What to do, right? One thing that's interesting is that I actually think this got a little easier now because it turns out that a lot of people who are getting started in technology now aren't that familiar with Windows or OS 10. So they don't have to unlearn the file GUI because they're actually not super familiar with it at all, like a file structure and a directory structure. They can just learn that new now.

It is kind of fascinating to be hanging out with somebody much younger than me and realize that they, too, like my parents, don't understand where a file goes when you download it. They can't necessarily find the file that got downloaded onto their computer because they're used to their phones and their tablets and the other interfaces that don't give you a file browser.

Anyway, so a really good place to start there's a textbook called the Linux Command Line by William Shotts. It's free. It's at linuxcommand.org. And it is a fantastic place to get started. It starts right from the beginning. It's like, hey, you're looking at this command prompt. What on earth is this? What do you do? And it's also a really good start because that book is like 800-900 pages long, or I don't know how long, maybe it's about 300 pages long. But it's long. And there's no universe where you would master that whole book before you got on to the next thing.

Aisha: Certainly.

Nočnica: That's a really good starting place is to say, hey, we want to understand this. But we have to know some certain point to say, okay, I get it enough to start with a little project. So I would say (Give me your thoughts on this.), but I would say a really good idea would be hey, what we're going to get to you in a couple of steps is we're going to get to a little Linux server, maybe just running on our laptop, that is running some kind of software and is responding to requests with some piece of software that we wrote.

Aisha: I feel like that's something...I want to say tangible, but that's something you can sink your teeth into. But it also gives you all the most basic pieces. And when you start to understand how those pieces fit together, then you're able to start building that mental model that you build off.

Nočnica: I think it's fair to say you want to have a tangible or a measurable goal because when you're first learning the command line, it is frustrating. You forget stuff; you go back. And it's hard to say at first, like, do I understand this? Yes or no? Am I further than I was before? Yes or no? It's tough to know that exactly.

And that's worth acknowledging because when you ask yourself later, like, is this a good use of my time? You should have some tangible goal you're trying to get to. So I think it's reasonable to say, hey, I'm going to give myself an amount of time, maybe six weeks, to be able to stand up a virtual machine on my computer that's a Linux server and that is running a little bit of Python and is responding to requests. It's like if you're working hard and you got kids and all this stuff, give yourself six months. It's not that it has to be on some timeline.

But it's also okay to say at the end of that, hey, did I get there or not, and do I need to change strategies? So that means one of two things if you get to that point is either you need to change strategies. Like, I always say it's great to start with resources that you can find for free. I personally never would have become a developer if that was the path that I was taking. I would have just never studied these things and gotten there. It's also okay to say, "Hey, turns out this isn't for me," right?

Aisha: Absolutely.

Nočnica: Yeah, it's not the end of the world to say especially, (well, stage 2 we'll get to) but especially if you really try to make a project, especially if you're accountable to someone else, and you have a list of features, and you need to code those up and deliver them, it would be great to try and do that once or twice before you jump into this career to know if hey, is engineering full time? Is that something that I would actually enjoy or would, in fact, hate? I think it's worth asking yourself that question.

Aisha: And I think your point about having a timeline even if it is I am choosing this timeline, and it is entirely on me, and no one else is relying on me. All of that is fine as long as you stick to it. Because in that sticking to your own personalized timeline, that gives you the opportunity to reevaluate and ideally without the shame that I think a lot of people tend to feel when it's like, oh, I don't know what I'm doing. I don't feel comfortable doing this. I'm not sure if I like this. All of that is okay.

Nočnica: Yeah, absolutely. I think it's also worth it to say, hey, if I was in a CS programming college, this would not be totally self-motivated, and I would have check-ins. And you might ask yourself how you can replicate that and say, hey, is there someone else I can have accountability to? Can I break this up into smaller chunks?

A great thing about having a text like Linux Command Line is that it is a really good way to say, hey, I have sections 1,2,3,4 here, and I want to move through these sections instead of taking this huge phonebook of information and saying, well, I'm supposed to be done with this in six months. And it's really hard to pat yourself on the back at the end of the week because you're not going to be very far through that in that amount of time.

So once you've gotten to the point of hey, you're kind of running this Linux server, running some Python or some Node code on that server is kind of the next step. And so you can find this is probably where people do know like, yeah, I can find a lot of tutorials to do this. You want to stand up code that is doing something really simple because you're not targeting being a full-time coder.

You just need to get familiar with once you write a piece of code; how do you make sure that when this server gets requests, it runs that code? So that's the concept of generally a web server is that it's taking in requests and it's going and saying, okay, this came in in this way, and therefore, I'm going to run this piece of code, and the code is going to tell me how to respond.

So ideally, you get to the point where you send in a request, and the request has a payload that's the number 10, comes back, and it gives you the number 20. It always multiplies those numbers by two or adds ten to them; however, you want to do it. I'm not going to define your math, but that's where you want to get to. That's now you have the basis for moving on to operations.

Now I will say I do not think that HTML and CSS, if you're targeting operations, is a good use of your time. So they are incredibly complex and erudite technical areas that you can learn for years. I think even a basic knowledge of how those things work is probably not something that you for sure have to cover early on here. You can get it sometime. And if you're interested, you can totally study it. But if you're really sweating HTML and CSS for six months and your target is to be in IT and operations, you're probably taking more time with that than you need to.

Aisha: Totally agreed. Now, if you're talking about I want to be a web developer, and you are ignoring those technologies in favor of JavaScript, that's a different conversation for perhaps a different podcast. [laughs]

Nočnica: Yeah. No, really worth saying. Like, anybody who says, "Oh, I'm a full-stack developer. I don't know any HTML and CSS," or like, "Hey, I make code that creates websites, but I don't understand HTML and CSS," you're shooting yourself in the foot there. That's not a way to do things. In the same way that Linux Command Line will teach you this or other resources will teach you this about file permissions, you want to do a little bit on that. You want to at least get to the point where you can edit and control file permissions in Linux because if you can't, you don't really understand that pretty basic component of how this stuff works.

So once you've got that little server again, it can be running on your laptop. It can be running on AWS. It can be running some other place, but you should be able to be in control of it. Now it's time to get into this operations side of it. So one very solid place to start the CNCF has like, I mean, it's a little silly, but it's Kubernetes for Children. It's like their Phippy page, P-H-I-P-P-Y, Phippy. And it's like a storybook for children, but it's in a very readable level to be like, what is it that we're doing when we're talking about clustering, containerization, and strategy? So that's really good to check out.

The next one would be Google. If you go to sre.google their books on how the SRE role came to exist, Software Reliability Engineer (SRE), right?

Aisha: Yes.

Nočnica: And that's from 2016. It is not out of date, though. It is still information that new organizations need to read and hear about. And that's really critical to do because, especially as you do engineering every day, you're not going to talk about architecture, organization management, and why things work the way they do. You're going to hear a lot more like, that's not my role, or that's not my responsibility. And we have these other people do it. But you're not really going to hear why.

And most shops are working in a way that these Google Books on SRE are really going to cover why that is this way. So again, link in the show notes to that, but I think it's worth reading. They're not long. And if you've gotten to this point, technically, they should be pretty readable what they're saying. They're not technical tutorials. They are high-level tutorials about strategy and how you handle problems, and how you handle uptime and stuff.

Aisha: I love that. Addressing the why of things is so important. And I think when we're getting into a field, it's really easy to focus on the what and the how.

Nočnica: Yeah, and I'll say also when it comes to organizational responsibilities to what makes good code, good software, good tools, if you go on a community site, even a relatively non-toxic one like Dev.to or what have you, you will find information that is dead wrong all the time. It will be the popular wisdom is like, serverless isn't that great because I can just build it myself. That's wrong. [laughs] But you find it every day. So try to consider the source when you're learning tech stuff, and that kind of matters. And we're not going to have time to cover this here.

But you don't want to go into interviews with a lot of odd toxic beliefs because, frankly, a lot of engineers these days can sniff that out pretty quickly. So if you have stuff to say like, "Well, I'm a really rational person, and a lot of people are really irrational. I care about facts, and facts is the real thing, and other people don't care about facts," eh, that’s...

Like, "Oh, I only write really good software. And a lot of people are too lazy to write good software, but I'm not." These are red flag emoji. So it's totally cool to read this stuff, especially the social media cadence makes it fun to read through this and like, oh yeah, hot story. Let's talk about it.

Aisha: Sure.

Nočnica: When you really try to see what's true and what's not, go back to something like one of these books. Go read something that Kelsey Hightower has written. Go read something that Charity Majors has written. Go read something that someone who actually works in the field and whose face is attached to their words and is not just making anonymous comments about what have you. I had a friend who shared one of their projects on Hacker News, and he shared an article that he wrote.

Aisha: Bold.

Nočnica: Somebody replied on Hacker News. "I looked through the project that you worked on, and one of the pull requests says that a bug had existed for over six months before you fixed it. So I'm not going to read anything you write because you're too stupid."

Aisha: Oh my God. [laughs]

Nočnica: That's easy enough to do when you're on Hacker News, and your username is weedlord290. As long as you can make just random, anonymous comments and no one can see your GitHub, that's for sure.

Aisha: [laughs]

Nočnica: By the way, literally every person who leaves comments like that their GitHub is a white sheet of paper for the last three and a half years because they've only done closed-source commits to their poorly run software shop. I guarantee you. But yeah, you want to make sure that your high-level industry stuff is formed by somebody who you actually respect, and what they're saying makes sense.

Okay, so you have that layout. Now it's time. Now it's Kubernetes time. And so I was just mentioning Kelsey Hightower. Kelsey has a tutorial called Learn Kubernetes the Hard Way. If you're capably running your own little hobbyist Linux server, then you should be ready to follow Kelsey's tutorial and get something from it.

If you go there and you hit a wall, and again you can run a Linux server on your own pretty well, then you should feel really comfortable posting either issues to Kelsey's GitHub or asking questions on Stack Overflow or Reddit or Dev.to. Say, "Hey, I'm stuck here. Can I have some help?" Because you have a pretty good basis. So, of course, you're going to get stuck. It's a complicated process. Now you have some understanding of what on earth you're doing.

And so that I think is the path to say, hey, I want to get that understanding. And the most important thing to keep in mind is that there absolutely are people who understand almost all of the Kubernetes API, understand almost every single operator command, understand kubectl really well, do all that stuff. Those people currently make $400,000 a year. That's what they're doing. And most listings are "Hey, we need somebody who understands anything about Kubernetes, can deploy it on any kind of public cloud." Those listings have been open for nine months.

So you really need to let the pressure off yourself to be like, I have to be really perfect at this. Lots and lots of shops now are hiring competent back-end coders, people who understand Linux to a degree. And then they're like, "Okay, now we need you to understand this Kubernetes stuff." And that's just the reality is a lot of places are training entirely in-house. Having some familiarity, being able to stand up and take down a cluster, trigger some scaling, and read some events, that's a really good start to say, "Hey, I'm going to go make a case for why y'all should hire me."

So take as much time as you want on Linux administration and understanding that. Deeper is better, and it's great to get some knowledge, getting all the way to the Kubernetes space. Of course, the other reason I'm soft pedaling that is, first of all, a lot of places will hire you with cursory knowledge or beginner's knowledge. Also, frankly, what you can simulate yourself in your little private cloud that you're spending five bucks a month on is --

Aisha: Exactly.

Nočnica: Yeah, the point of implementing continuous deployment, continuous integration, doesn't really make any sense. So like, you see CI/CD alone. So there's just going to be a level that, like, okay, I can't simulate it at all. So even if you spend an extra year really leveling up on that stuff, it's not necessarily going to be that applicable. So better to say, hey, now, it's time to get some real-world experience with this.

Aisha: Makes a lot of sense. So I'm here now, and I'm looking maybe what are some things to look out for? What are some red flags? How should I be looking to level up once I have found a team and I'm working at a larger scale?

Nočnica: So one thing I would say is that it is more fun working for a startup, and it's easier to get a startup to take a chance on you. I would say it's worth considering if you really are just starting out that that startup is not going to generally have the resources to train you effectively.

If they're saying, "Hey, Kelsey is amazing. She knows everything, but she does need help. She's going to be training you an hour a day." Fantastic, go take it. That's not usually the situation the startup is in. Normally, there are a lot of fires that people are putting out. It's a lot of work that people are doing. And so when they're hiring, they're hiring somebody to work full-time in the field. So that can be a little tougher.

Now, obviously, an enterprise can also be very bad at training people and have no plan to train people, but it is more likely that those resources are going to exist. And I would say probably the worst thing to do first is, hey, nobody here knows anything about this cloud, about AWS, Azure, whatever, and nobody knows anything about Kubernetes. And we need you to do it all. And you do see that quite a bit.

You see a lot of wishful thinking listings that say, "Hey, probably we're in a bad state, maybe even we deploy the cluster, and we're even sending production stuff to it, but we do not know how to manage it or control it. And we need someone to get us unstuck." And what those people should be doing is going and spending half a million dollars on a consultancy to fix the problem.

Aisha: Exactly.

Nočnica: And instead, they're trying to hire someone and offering them $64,000 a year, so good luck. That's its own category of things to look out for. It's great to believe in yourself, but do not go take a role where you're going to be the apex of knowledge as your first or second role. Ask questions right away about hey, what is the plan for training and skills growth? Who's here? And how much time out of the day are they going to be able to commit to it? Or is it going to be when I get to it, I'll only answer a few Slacks here and there? So yeah, I think that's the basic.

There's really great advice out there about pay and stuff. Frankly, as a white woman working in the tech industry, I really can't give you a lot of advice about that stuff. You're going to experience very different stuff coming into it than I will if you're not from this white West Coast background. So I won't speak to any of that. And also, I think I will say your skills leveling up are the important part. Probably that 10% pay or something is not going to be worth very much if you're not growing your skills in some other role.

So, if you're in that situation and you want some real talk about it, hey, come message me. I'm at twitter.com/Serverless_Mom. And I'm happy to chat about it. I get DMs pretty frequently, like a couple of times a week, that are like, "Hey, I have these roles. What should I take?" and stuff. That's pretty gratifying. It's actually super nice to do. It's kind of a fave. I can't speak to all the other career path stuff but definitely look for a place that's developing your skills.

Aisha: Absolutely. And I think that makes sense just any kind of engineer really, look for those opportunities to grow in the areas that you want to grow in. And, ideally, have some idea of where you want to take things, but I would say be open as well. There's always the chance that you're going to try something, or you're going to see somebody working on some tangentially related thing and be like, you know what?

Nočnica: That's what I really want to do.

Aisha: That sounds like a lot of fun. And even within the same role, there are hopefully going to be opportunities for you to try that thing and say, you know what? Actually, I like working over here with Angie. I'm going to do what Angie is doing and learn about that. Or I'm going to go over here and work with Bob for a while. And that kind of exploration becomes possible when you open yourself up.

Nočnica: Yeah. And one of the things we don't talk about or often gets soft-pedaled is people talk about what they make in dollars in tech, but one of the privileges that we really don't discuss is you do generally have that flexibility to say...hey, hopefully, the money introduces a margin to your calculations to say, "Hey, I don't have to just go make the decision that pays the absolute maximum amount of money." I can say, "Hey, this is the style of work that I actually like to do."

When I got started, I always said I wanted to move into DevRel and the more marketing-focused stuff. For a while, I needed 100% of my pay to pay my bills. I was working for somebody where you'd hand off an article to him, and he would say, "Okay, I have these notes. Come back." And then I'd be like, "Okay," and I edit it. And then he'd be like, "Oh, I have more notes now." And not all the stuff that you had edited, just other stuff. And by the time I had my second role in that field, I was able to say, "No, no, no, that's not going to work."

Aisha: [laughs]

Nočnica: The same thing happened like a year and a half later, and I said, "That's fine this one time, but that cannot be the workflow." That's maddening. You send it to me; I edit it. You edit it, I revise it, then we're done. Just come on, that's just crazy-making. And that was definitely...I was working in this highly technical field. I was writing highly technical stuff. And so there just wasn't...I was able to say, "Oh yeah, you can't do that." But if you just work in regular content writing or just any sort of…thing, you just have to deal with whatever workflow you're handed. So that's a real thing to identify.

And also, it's really real to say that's really what you're seeking when you're seeking a tech role and saying, "I want to be able to have that flexibility." Because once you've done one of these engineering roles for a couple of years, your ability to say, "Hey, no, I really like going to parties and organizing events and writing stuff, and so I want to do DevRel all the time." That's very accessible.

If you say, "Hey, I like working with customers and making deals and doing that stuff," solutions architecture is open to you. And there are 100 other directions. As long as your real happy place isn't driving a tractor across a field of corn, you should be able to use your development skills to do something fun. Actually, there are developers who work for John Deere, and then they get to drive a tractor around.

Aisha: [laughs] That's true.

Nočnica: I knew somebody once who said that his dream job was...there was like a Java developer for Caterpillar. And in the afternoon, you would go test your software by moving gravel around and stuff.

Aisha: I live in Detroit now, and I have known a whole lot of developers who work on cars, and it's not even always directly relevant. Sometimes it's just like, yeah, I got to go and ride along at the Ford Test Track, and I'm like ooh. [laughter]

Nočnica: I'm terrified because that to me sounds like, hey, we all got an opportunity after we wrote our code to die. [laughter] That's what I like.

Aisha: Definitely an adrenaline rush for sure. [laughs]

Nočnica: I was talking to one of the Serverless AWS Heroes. And he's got this car where he's like, "My truck is being nice, and they're not making me install a roll cage in the car because it goes this fast, and it really should have a roll cage already." It's stressing me out hearing that. All right, so what else do we need to make sure people know?

Aisha: If you have a bead on community shout-outs.

Nočnica: So join Portland Containerds. PDX Containerds on Meetup. You can find the links on my Twitter @Serveless_Mom. We meet up every month. It's a pretty fun one. Take a look at Dev.to if you haven't, especially if you're trying to get started in the industry. Yes, we mainly talk about JavaScript and PHP, but I promise that there are also AWS people and other people on there. What else do I recommend people do? That's it.

Get a Twitter account and follow some people that you like. Unfollow anyone who's tweeting a bunch of...anybody whose face is inside a hexagon on Twitter just move on. I love you, and I want you to have joy in your life. Did you follow an account two years ago that posted really cool art and animation, and they suddenly started just posting weird stuff that looks like it's from Second Life? Just unfollow them. Don't even worry about it. Give yourself peace. Give yourself the gift of peace. Just move on. Stay off Reddit, kids. No, I don't know.

Aisha: [laughs]

Nočnica: Here's something that I'll tell you. Really early on, it can be great to share your path and what you're learning. If you have career questions, it is fine to post on Reddit and see what people say. You might get some helpful advice. If you have early code to share or stuff you want to show people, keep it off of Reddit and Hacker News and go post it on Dev.to.

Because at Dev.to if you post here's how to store everyone's passwords in plain text, you'll get comments back saying, "Maybe don't do that." If you post very capable file compression algorithms to Reddit, people will comment on it telling you that you should burn your computer in a fire. I really mean this.

Share your early career stuff but think about the platform. Look at the culture that you're interacting with and make sure that you're picking one that is supportive. So I very often find great people on Twitter. You can find great people on Dev or Dev.to, great places to start there. And yeah, just go read the comments on other sites and don't take their criticism or weirdness too personally.

Aisha: I feel that, yeah. And Twitter and Dev are also really solid places to look for mentorship, which does not necessarily need to be a one on one relationship. You want to look for people who are doing the kinds of things that you want to do and see what they're talking about, see how they are thinking about building their own skills. Look at the things that they have already done and see what parts of that journey are interesting to you.

Nočnica: I really feel that. I will say the last thing if you have access to it, especially if you feel that you are in a job now that is making you really miserable, if you have all your bills paid and you still say, "I need to change careers, or I'm really, really sad, or I'm really, really struggling," get therapy. Try to get some time to talk to somebody about it.

Because I was certainly somebody who gave herself a lot of opportunity and a lot of privilege and ability but was still just absolutely miserable, so go talk to somebody. It does help, and it's not an admission of failure. And then I promise that the feelings of success and actual success will follow that. So on that extremely real note -- [laughs]

Aisha: All right, I want to thank you so, so, so much for joining me and having this conversation. I really appreciate it. And I feel like you came away with some super actionable things for folks, and so thank you.

Nočnica: I'd love that. My only regret from this podcast...please do go look me up on Twitter so that you can find out that I have chrome teeth. I will tell you that no one who talks to me on video can think about anything else when they talk to me. So it's just a real disappointment that you don't get the full experience with audio. But yeah, look up my photo and just imagine. Thank you so much, everybody.

Aisha: All right, thank you so much for listening. Be sure to check out our other podcasts, Launchies and Observy McObservface.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.