[00:00:00] SY: Tickets are now available for our fourth annual Codeland Conference, taking place July 23rd and 24th in New York City. It’s the welcoming conference that brings together code, culture, and community, which promises to level up your software career. You’ll experience amazing talks and workshops led by an inspiring lineup of speakers. Tickets are currently on sale at codelandconf.com. See you in New York.

[00:00:32] Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host Saron, and today we’re talking about Site Reliability with Molly Struve, Lead Site Reliability Engineer at DEV Community.

[00:00:47] MS: The way I feel is that you’re never too small to have an SRE. Even if it’s not someone who’s just a sole SRE, maybe it’s someone who has the SRE mindset.

[00:00:58] SY: Molly talks about going from studying aerospace engineering to becoming an Options Trader, to then becoming a Site Reliability Engineer. She gets into the history of site reliability, what it is, and what it takes to do it well after this.

[00:01:19] Career Karma helps code newbies with free career coaching to help them learn to code and find a high-paying job in tech in less than a year. Download the Career Karma app to start your 21-day challenge and be one of the over 60,000 people who they’ve helped get started. Visit careerkarma.com/codenewbie.

[00:01:40] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. It also lets you use the most popular open source languages to build web apps.

[00:01:56] Learn how to code online with Educative’s text-based courses with in-browser embedded coding environments. With their newly launched Educative’s subscriptions, users can now get unlimited access to every course offered with a single fee. Get 10% off site-wide by going to educative.io/codenewbie.

[00:02:17] DigitalOcean offers the simplest, most developer friendly cloud platform. It’s optimized to make managing and scaling apps easy with an intuitive API, multiple storage options, integrated firewalls, load balancers, and more. Get started on DigitalOcean for free with the free $100 credit at DO.co/codenewbie.

[00:02:46] SY: Thank you so much for being here.

[00:02:47] MS: Thanks for having me.

[00:02:48] SY: So let’s start with your journey. Where did your coding journey begin?

[00:02:52] MS: I actually started coding in high school, and then when I went to college I thought, “Okay, I want to be an electrical engineer.” My dad was an electrical engineer. So that seemed like a good path to follow. So I enrolled in the intro to Python class, and as I’m taking this class, the guy who lives next to me is taking the intro to aerospace class. And so every day he comes over and he’s like, “Oh, guest what we get to do? We get to build a rocket. We get to build a parachute.” And I’m thinking to myself, “Hmm, that sounds a lot more interesting than typing on a computer.” So I ended up switching into aerospace engineering. I got an aerospace degree, and it wasn’t until two years after I graduated that I found my way back to software engineering when I decided to change careers and become a software engineer.

[00:03:48] SY: So when you were majoring in aerospace engineering, what were you hoping to do with that?

[00:03:53] MS: Honestly, at the time I thought it would just be awesome to build airplanes, but unfortunately, the airplane industries are either out in California or in Seattle, and often you’re working for these big companies like Boeing, and that’s just not something I really want to do. I really kind of wanted to be in the Midwest, in Chicago since that’s where my family is. So I kind of passed up the aerospace path and actually ended up going into options trading since that’s kind of a big market in Chicago is the finance industry.

[00:04:26] SY: Wow! Okay. That is a big jump. I would not have guessed that. Tell me how you got from aerospace engineering to options.

[00:04:36] MS: Yeah, so aerospace engineering was my degree, but during college I actually interned at a trading firm because my in-laws at the time owned a trading firm. So I ended up interning there. And then after college, it’s kind of the path you follow wherever you intern usually you end up with the job there. So that was kind of the easy path. And so I just kind of followed that path. And it wasn’t until two years after I’d been trading that all this stuff was happening in Silicon Valley. You had Facebook, Instagram, all these companies were really starting to change the shape of the internet, and I saw that and thought, “Wow, that looks way more exciting than betting on which way the stock market’s going to go.” So I literally quit my job and teach myself web development so that I could go and join the fun basically.

[00:05:33] SY: So when you were doing options trading, it sounds like it’s not that you hated finance, it’s just that you saw something better you could do.

[00:05:41] MS: Exactly. Finance and trading, you do a lot of the same things we do as engineers. You’re looking at problems. You’re trying to find ways to solve them. But in the finance world, you’re doing it to make a bet. My engineering background made me want to actually build something, made me want to really do something with those problem solving skills as opposed to just making bets. And so I think that’s really what drove me back to creating stuff and being on that creation side of being an engineer.

[00:06:15] SY: So you mentioned that there were all these things going on with Facebook and then other big companies really blowing up. And I remember that time period too. I remember being just really in love with the idea of startups and this idea of building something from nothing, but it still took me a while to find out what the jobs were to be in that industry. You know, like it took me I think another two years to figure out, “Oh, I need to be a software developer.” So for you, what was the journey going from, “Wow, look at Facebook,” to, “Okay, I need to quit my job to learn how to code”?

[00:06:48] MS: I kind of figured out pretty quickly like, “Okay, if I want to build a website, I need to be a web developer.”

[00:06:56] SY: Fair, logical.

[00:06:57] MS: And that’s fairly the train of thought. So I was honestly stewing about this and stewing about it, and then something happened. My husband got really sick and ended up in the hospital for a few days with basically a really bad case of pneumonia. And of course, what do you do in a hospital? You reevaluate your life decisions basically. So it was literally there. I looked at my husband and I said, “What do you think about me pursuing software engineering? What do you think about me quitting my job and teaching myself web development?” He kind of thought I was crazy, but he said, “I will support you. I will back you. I’ll give you whatever you need. I think you’re a little bit nuts, but I’m behind you for whatever you want to do.” And so that was literally the point where I can say, “I made the decision that, okay, this is going to happen. I’m going to quit my job and do this.”

[00:07:52] SY: What was it that seemed so crazy to him?

[00:07:55] MS: I think it was partly because at the trading firm I was working, like I said, for my father in-law’s company. So I had the ultimate job security. The company has been around for a while. I wasn’t going to lose my job for some random reason. I was working for my family. I was in the family business. I mean that is as stable as it gets. But me, I’m not about stability. I’m about finding something I’m passionate about and doing what I love. And so my husband, on the other hand, he’s a little bit more just kind of like, “Oh, you know, if we got something that’s working, like why change it?”

[00:08:31] SY: Yeah. My husband’s exactly the same way and I’m just like you.

[00:08:35] MS: Yup. Yup. You’re just flying off.

[00:08:38] SY: Yup. I’m with you. Okay. So you said that you quit your job and you’ve learned how to code on your own. Tell me a little bit more about that. What resources did you use? How did you keep yourself motivated? Tell me about it.

[00:08:50] MS: Yeah. So I quit my job and the first thing I did was I found the Michael Hartl tutorial online.

[00:08:57] SY: Yeah.

[00:08:57] MS: I believe I literally just got on and Googled how to learn Ruby on Rails because that’s what I heard was what everybody was using. How to use Ruby on Rails for free? Because I don’t want to pay for it. And I found the Michael Hartl tutorial and I actually have a picture of this, but I printed out the entire tutorial and went through it and I’ve got like all my highlighted notes and whatnot, and basically built the application. The Michael Hart tutorial, what it walks you through is building a mock Twitter app. And so I built the application, but then tweaked it to be my own website that I’d kind of hoped would get off the ground. It was called WaterCoolerMeetings.com. And my whole kind of idea was, “Okay, I’m going to start this company, and the purpose of the company is going to be like LinkedIn, but with the focus on people meeting people and mentoring each other.” So I ended up doing that for probably three to four months. And at that time, so I’m thinking this is probably 2012, I didn’t really know about Twitter. There weren’t many communities out there for new developers. What CodeNewbie has done and what all these other communities have done is just incredible, and I totally wish I had had that when I was starting, but I didn’t. And so naturally after spending a few months doing this, I felt pretty isolated and really kind of wanted to get back out there and get on a team again. So at that point I decided to start looking for a job. And I didn’t really know how to do it. So I just went on Hacker News.

[00:10:41] SY: Oh!

[00:10:42] MS: And I was in Chicago. So I was looking for companies, kind of either in Chicago or in California, and I literally just started emailing people. And the company I emailed, it was called Aisle50, it was a coupon company, and they were looking for an engineer, a software engineer with two to three-years’ experience. I had zero, but I emailed them anyways and I said, “Hey, you know what? I’m looking for a job or an internship. I just really want to learn. Look at this website that I’ve built. What do you guys think about taking on an intern?” And they were willing to do it.

[00:11:22] SY: Oh, wonderful. Okay. So that’s really where you got your first real world experience. You were able to grow. Did they end up hiring you as a full-time developer after your internship?

[00:11:31] MS: Yup. So I did. Six months’ worth of an internship there. And I’m one of those people that I knew once my foot was in the door, I was going to smash that door down and there’s going to be no question about it. So after six months, they hired me full time and kind of the rest was history after that.

[00:11:48] SY: Wow. Okay. So you were doing web development, which is pretty different from what you do now, which is site reliability. They’re related for sure, but they’re still pretty different disciplines. Tell me what is site reliability?

[00:12:03] MS: Site Reliability Engineering, the way I like to describe it is it’s software engineering, but with the focus on making systems more reliable, stable, and scalable. So rather than being a software engineer that focuses on features and adding things to platforms, my focus is on making sure those platforms are stable, making sure that they can scale and things along those lines.

[00:12:33] SY: Okay. So tell me about a problem that you might encounter in site reliability land.

[00:12:39] MS: Kind of one of the common problems that I think a lot of site reliability engineers deal with is scale. So one of the things you have to be very in tuned with as a site reliability engineer is your overall architecture. So site reliability engineers usually have a really good ability to step back and look at an entire system. So you’re looking at your things like your web servers, those servers that are serving, literally traffic that comes in from the web. And then they’re also looking at, “Okay, what kind of databases do we have? How are all these pieces interacting?” And when you go through things like a lot of user growth or you add a lot of data to your system, one of those pieces is eventually going to become your bottleneck, whether it’s your database or whether it’s your ability to serve traffic from the web and as a site reliability engineer, you kind of have to try to figure out where that bottleneck is going to be before it actually happens so that you can fix it in a sense or shore it up so that when that traffic comes in, when that data comes in, your site doesn’t fall over but can handle it and you can kind of scale it and continue to grow.

[00:13:51] SY: So would you say that site reliability sits next to web development? Is it a specialization of web development? Where does it sit kind of in the ecosystem of different jobs and roles you can have in tech?

[00:14:05] MS: I think it definitely sits next to web development and I think it compliments it very well as web developers or software engineers, they’re building all these features and they’re building websites. I think ideally every one of them should have a site reliability sitting next to them basically just saying like, “Okay, are these decisions we are making to add certain things for features, certain databases, et cetera? Are they going to be advantageous for us in the future?” Because as web developers are building their web application, they might say, “Oh, I need a database to hold this data.” Well, the site reliability engineers then can say, “Okay. I see the data you want to store, here are your best database options based on what you want to use it for.” And it’s kind of the marriage of the two. They can figure out, “Okay, how do we build the best system that we got all this data, we’re going to present it the way we want to, but at the same time, in the back end, it’s going to be reliable and accessible quickly?”

[00:15:20] SY: Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Also, you’re not walk-in to the service. So why not start building your apps today with Heroku?

[00:15:45] Career Karma is a free service started by bootcamp grads for bootcamp grads. Coaches are current coding bootcamp students who mentor people to help prepare and get accepted to bootcamps in just three weeks. We spoke to Kesha Lake who used Career Karma and is now an engineer at Stitch Fix.

[00:16:04] KL: I was really looking for a way to jumpstart my career, but not just getting me ready for the career itself, but to get me ready for bootcamp. I figured if I can do the 21-day challenge, then I can do the bootcamp.

[00:16:16] SY: So what was the challenge? What was it like?

[00:16:19] KL: The instructions were to speak to one person on your level and one person above your level every day and then post some sort of proof about it as a screenshot or a picture.

[00:16:29] SY: Did you know anything about coding before this?

[00:16:32] KL: I knew absolutely nothing about coding. So the 21-day challenge really set me up perfectly. I made friends, I started networking with people who would eventually make recommendations for me to get the job that I landed, but they also offered a lot of resources and support. You know, initially I was coding on my phone because I didn’t have a working laptop. Career Karma put me together with another one of their members who donated the first laptop and then I do get to upgrade to a Macbook so I’ve got another laptop from the Career Karma community.

[00:17:00] SY: So what kind of work do you do at Stitch Fix?

[00:17:02] KL: So I work on automation projects that help plan of ease the burden of our warehouse workers. So I kind of do a lot of telling machines what to do, which is exciting. It’s mostly back end work.

[00:17:10] SY: That’s fancy.

[00:17:12] KL: Yeah, it is. It’s kind of sexy and I’m really excited about it. I really leaned more towards back end development as opposed to front end doing bootcamp. So to find a job that would let me focus on that is kind of a dream come true.

[00:17:24] SY: Visit careerkarma.com/codenewbie to get started. So you started off in web development. You are now in site reliability. How did you make that transition?

[00:17:39] MS: So that transition for me actually happened when I was at Kenna Security, which is where I was before DEV. I was there for over four years.

[00:17:48] SY: Wow! That’s forever in tech land.

[00:17:50] MS: Yes. Right?

[00:17:52] SY: You must have really liked them.

[00:17:54] MS: Oh, even when I left, it was hard to leave. But that’s a story for another day. So at Kenna I joined, I was based mid-level software engineer when I joined and at the time we had a couple of senior engineers and they ended up quitting and leaving for other companies. So when they did, we had this database, it’s called ElasticSearch. And when the senior engineers left, there was really nobody to take ownership over that database, and it was a core piece of our infrastructure. So I thought, “Hmm, I know nothing about ElasticSearch, but I’m going to try to take ownership.” I saw that as my opportunity to kind of grab ahold of something and run with it. So I did. And over the next couple of years, I learned everything I could about this database and ended up being the residential expert on it. And so when our team got so big that we had to make multiple DEV teams and our platform got so big, our VP came to me and said, “Hey, you’ve been working a lot with this database. Basically your function right now is a site reliability engineer. What do you think about breaking off and forming a site reliability engineering team, and then you literally just focus on making sure this database along with all of our other databases are performant and play nice with the code?” And that’s what I love doing. So I immediately said yes.

[00:19:23] SY: So when you are doing all this SRE, right, is what they call it, Site Reliability Engineer.

[00:19:28] MS: SRE, yeah. So anytime you see SRE, site reliability engineering is what that stands for.

[00:19:34] SY: And so you mentioned earlier that not every company has SREs. At what point do they have a site reliability engineer?

[00:19:44] MS: So the SRE book, which was written by Google, a lot of people I think when they read that book, you look at Google, Google’s huge, and so I think a lot of people have this assumption that you can’t have an SRE team until you’re very big, and that’s kind of how it went at Kenna. We didn’t form a site reliability team until we had over 15 engineers. But the way I feel is that you’re never too small to have an SRE. Even if it’s not someone who’s just a sole SRE, maybe it’s someone who has the SRE mindset. But I think having that SRE mindset and having someone who’s looking out for those reliability, those scalability issues right from the get-go is essential in making sure that you create a platform that’s going to be reliable and scalable. I can tell you firsthand, when I was at Kenna, a lot of the times we had to like kind of fight fires and we would scale past what we were capable of. And so it was kind of a mad rush to fix things. Now that I’m at DEV and I’ve been brought in so early in the platform, all that kind of panicking chaos that can often follow site reliability issue, there’s really none of that because the platform is still small and I kind of have a chance to just kind of breathe and just set it all up so that when those big gross come, hopefully it’s not crazy and chaotic. Hopefully, it’s just, “Oh, we should probably tweak that setting there. I didn’t quite see that one come in. So let’s do that.” So I think by having that SRE mindset, you can get out ahead of those problems before they even become an issue.

[00:21:32] SY: So I want to dig into the history of site reliability engineering because even it as a discipline is relatively new. Is that right?

[00:21:43] MS: Yeah. So like I mentioned before, the SRE Google Book kind of was at the forefront of defining SRE as a field in general. Another term that people use sometimes to define SREs is DevOps.

[00:22:00] SY: Right. Yeah.

[00:22:02] MS: But kind of the difference I see between DevOps and SRs is I think SREs at a core are software engineers that might just have a little bit extra experience in like a database or maybe they’re very familiar with a certain server type. Whereas DevOps to me, really sits between dev and operations and really handles a lot more operations stuff. They might not be as concerned with stability and reliability.

[00:22:29] SY: So when you think about the skills of a web developer, software engineer and compare that to the skills of a site reliability engineer, what are some of the big differences between those two roles?

[00:22:41] MS: I don’t think there are many differences per se. The way I look at it is that site reliability engineers are kind of built in my opinion on top of web developers or on top of software engineers. So when you’re a web developer or a software engineer, you’re kind of looking at a small picture. You usually give in a small space or an application to work within and that’s your focus. As a site reliability engineer, you’re asked to then take another step back and look at the broader picture. So what I kind of tell people who want to go into SREs, my advice always is do some software engineering, do some web development, figure out what you like, and then if you decide you want to work with databases, you really want to work on big picture stuff, then go into SRE. But I think having that year or two of just kind of getting your hands wet with coding, getting a feel for coding, architecture, all those basics is really good and is only going to help you when you become an SRE.

[00:23:48] SY: So when I think about your job and just the way we’ve been talking about site reliability engineering, it feels like in the best-case scenario, you are preventing serious issues from happening. And then maybe the other side of it, I guess the worst-case scenario is you’re fixing really big issues that have already happened. Can you tell us a story about some serious issue that you encounter that you’re able to solve?

[00:24:11] MS: There’ve been multiple times where when I was at Kenna, we’d be sitting there. Our day would be going along normally, and then all of a sudden, the grasps for ElasticSearch would spike, and then all of a sudden, the ElasticSearch servers would fall over and crash. Well, when that happens, we totally lose the ability to search. So that is not good.

[00:24:34] SY: Kind of a big deal.

[00:24:35] MS: So I can distinctly remember scrambling when this happened, being like, “Oh my God! Get the servers back up. Get the servers back up. What is happening?” And so we stand the servers back up. Boom! They go down again. And you’re thinking, “Oh my God! I can’t figure this out.” And so during those times, usually what you go to is you go to your monitoring tools, you go to your logging, and you literally just start digging through as much as you can, trying to figure out what’s going on. So in this case, I ended up looking at a bunch of logs and we found a query that was horrible and was just wreaking havoc on ElasticSearch. And so we figured out how to rewrite that query so that it wouldn’t hurt and take down our cluster and push the fix and boom, everything was fine. But you definitely have those moments as an SRE where stuff just blows up. And in those moments, you really have to keep a level head. And one thing that our VP of engineering instilled at us in Kenna is, and it doesn’t apply to everybody, but it applied to us, is he looked at us whenever we had big incidents or stuff that kind of put us down anytime a website goes down, anytime something you built has a problem, like you take that kind of personally, he would look at us and he’d go, “No one died today. Literally, the software we’re running, we’re not saving children here. Someone couldn’t look at their data for 10 or 15 minutes. It’s not the end of the world and just remember that.” And so that’s kind of what he used to help keep it in perspective. And I think that goes a long way that when I’m dealing with incidences or when a website goes down or a database crashes, like you just got to keep a level head and you just got to try to work it out and puzzle it out and fix it to the best of your ability.

[00:26:31] SY: I was wondering about that because from everything you described this sounds stressful. It sounds anxiety inducing to be in a situation where when something breaks, everyone kind of turns to you and goes, “What are you going to do about it?” And it may not be a problem you’ve seen before or a problem that you’ve created and you still have to jump in and fix it. And there’s a huge time pressure. Were you always so level headed or is that something you had to learn to be?

[00:26:58] MS: It’s kind of something I’ve had to learn a little bit. And I think having really good coworkers, having that VP of engineering kind of along the way has helped really shift my mindset so that I can be level headed, but it’s definitely something you just kind of have to learn and it’s not for everyone. I have been through so many incidences so many times when things have gone down that now it’s normal for me. When you’re starting out, anytime you’re starting out, even when you’re a new developer, your first production outage, it is horrifying. You are shaking in your boots, freaking out when it happens. But as you’re an SRE longer, you just see it more often and it becomes, I don’t want to say normal, but it’s part of the job. When I think something that I really thrive on is I know at the end of every incident I’m going to learn something. So I’m going to learn something about our system. I’m going to learn something about a technology, and there’s kind of a rush to figure that out and be like, “Oh, what am I going to learn from this? Like I know it’s going to be something good.” And that kind of continues to drive me. And every incident you learn something new and you’ve got something one more experience you can kind of put in your toolbox. And so once you get a bunch of those experiences built up, then when these incidents pop up, you recognize patterns and it helps you solve them a lot faster.

[00:28:33] SY: Coming up next, Molly talks about her site reliability role at DEV and the importance of good mentors and a supportive team in your coding journey after this.

[00:28:52] With DigitalOcean’s cloud infrastructure, you’ll be able to build faster and scale easier from predictable pricing to flexible configurations, to world-class customer support. You’ll get access to all the infrastructure services you need to grow. Plus, DigitalOcean’s community provides over 2,000 tutorials to help you stay up to date with the latest open source software, languages and frameworks. Get started on DigitalOcean for free with a free $100 credit at DO.co/codenewbie. That’s DO.co/codenewbie.

[00:29:28] If there’s one thing that comes up over and over again in our podcast, it’s that everyone has a different way of learning. We had our producer, Levi Sharpe, try out Educative to level up his Python skills. And he really took to the service’s text-based courses with in-browser embedded coding environments. And Levi, what did you take?

[00:29:48] LS: I took learn Python from scratch, so I’ve been learning Python a little bit. So I was a little bit familiar, but I found that these courses, they’re laid out in a really intuitive way. There’s like these sections that lead seamlessly one into the other. The Python 1 goes from data types and variables to conditional statements, functions, loops, and then each section has a quiz to make sure that you’re not just blasting through and like the information is going in one ear and not the other.

[00:30:20] SY: I love the quizzes.

[00:30:21] LS: Yeah. It really called me out on my BS because I was like, “Yeah, yeah, I get it. I get it, I get it.” And then I took the quiz and they were like, “You don’t get it.” And I was like, “Ah!”

[00:30:31] SY: You got me.

[00:30:32] LS: You got me. And then throughout all of these different sort of sections, you can code within the service itself. So you don’t need like an external coding thing. I should know what that’s called. Do you know what that’s called?

[00:30:47] SY: I’m not going to tell you. I’m not going to give you an IDE.

[00:30:50] LS: Yes, that’s what it says, an IDE. Did you know I’m a producer for a coding podcast?

[00:30:56] SY: A technical podcast.

[00:30:57] LS: Yeah.

[00:30:57] SY: Two actually, two technical podcasts.

[00:30:59] LS: That’s true.

[00:31:00] SY: Get 10% off site wide by going to educative.io/codenewbie. You just started at DEV as a site reliability engineer. What is your day to day look like?

[00:31:18] MS: So right now it’s kind of a combination of things. So I am working on putting a lot of things into place. So at DEV, I am working to improve our monitoring. We have monitoring that’s kind of just all over the place. We’ve got one tool over here and one tool over there and just a bunch of different things doing different stuff and monitoring different aspects of our infrastructure. So one of the things I’m trying to do is consolidate all that so we get a really clear picture of how our infrastructure is behaving. In addition to those kinds of projects of making monitoring infrastructure more reliable, I also get to do a lot of investigative work. So usually once every couple of days we’ll see a little slowdown on the site and I get to be the one to dive into that and be like, “Okay, what was the problem here? Oh, it looks like this endpoint was a little slow. Why is that a point slow? Oh, it looks like this database query needs an index on it to speed it up.” And so kind of going through an end. So it’s a combination of laying that foundation and then also kind of investigating stuff that just might need to be shored up right now.

[00:32:29] SY: It sounds like the two companies that you worked for are very different. It sounds like the first one is maybe a little bit more stable, definitely bigger. DEV is much smaller and I think a startup, right? Technically it’s been around for just a few years.

[00:32:42] MS: Exactly.

[00:32:44] SY: Yeah.

[00:32:44] MS: Which is not too far off from where Kenna was. So when I joined Kenna four plus years ago, it was a 30-person company, so very small. And then just recently when I left, it’s getting close to 200.

[00:32:58] SY: Oh wow!

[00:32:59] MS: Very big. So like I got to grow a lot. I got to see a platform really go through all those growing pains, which was awesome and I learned a ton. And so what I kind of saw, and one of the things that really drew me to DEV was it was an opportunity to kind of do that all over again. I get to go join this small team, build and work on this platform that I wholeheartedly, fully support the mission for and gain the opportunity to do that was literally one that no matter how much I loved Kenna, I just couldn’t turn down. And so I’m super excited to go back to being on that small, tiny team and just building it from the ground up.

[00:33:41] SY: I’m wondering what your opinion is in terms of types of companies to work for if you’re just getting started, right? Because on the one hand, at a small person company, I can see that being a huge growth opportunity. You get to take on responsibilities that maybe you wouldn’t be allowed to take on at a bigger company, but at the same time, it can also be chaotic. There’s just a lot more going on, right? Not unnecessarily as organized, processes aren’t in place yet. So I’m wondering, when you think about the types of companies that a new developer could work at, what recommendations, what thoughts do you have?

[00:34:16] MS: I think it’s kind of less about the company and more about the people at the company. So there’s definitely something to be said about, if you go to a startup, there’s going to be less processes in place. There’s going to be less structure, but I think even with less structure, you can still have the support you need. So the first company that I worked for, that Aisle50 company that I mentioned earlier, there were three developers and me. So the tiniest of tiny startups, but those three other developers were incredibly supportive. They taught me everything. I still basically say, “Hey, you guys were the ones that really solidified and laid the foundation for my career.” So I think a lot of it depends on the people. And what I always tell people when they’re interviewing is, “You got to remember the interview is a two-way street. Make sure you’re asking all those questions like, ‘How do you like to teach developers? How do you feel about mentoring? What kind of opportunities are here for junior developers, for less experienced developers?’” I didn’t even know those questions to ask when I was starting out. And I just got incredibly lucky. That’s something I am very grateful for. But I think it’s about the people. You can find supportive people at big companies and you can find them at small companies. And I think if you really find that supportive culture that’s their sole purpose is going to be to help you grow and turn you into a good developer, that’s what you want to be looking for, especially when you’re starting out because I’ve heard of people who’ve had horrible experiences and they’re so hard to recover from those. But if you get a positive experience, it’s life changing and it just propels your career.

[00:36:13] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Molly, are you ready to fill in the blanks?

[00:36:20] MS: I’m ready.

[00:36:22] SY: Number one, worst advice I’ve ever received is?

[00:36:26] MS: Any personal advice. So anything where someone says, “Hey, this made me happy. I think it’ll make you happy. You should do it.” Anything along those lines, I’m a big proponent of, “You got to do you. You got to do what works for you.” So anytime I usually receive advice like that, I kind of just ignore it. I’m like, “Okay, I’m going to do what I need to do.”

[00:36:49] SY: Yeah. Okay. I like that. Number two, best advice I’ve ever received is?

[00:36:55] MS: To do what you love and the rest will work itself out. That’s something I’ve always done, and I think maybe it’s because my parents kind of taught me like never settle for anything less than what excites you, but I really found that when I’m doing something I love, it’s not a job. It sounds so, so corny, but I couldn’t imagine waking up every day and not being excited to do what I do.

[00:37:25] SY: Number three, my first coding project was about?

[00:37:30] MS: Like I mentioned earlier, WaterCoolerMeetings.com.

[00:37:33] SY: Yeah.

[00:37:34] MS: Actually, it’s still on Heroku. It’s like HerokuApp.WaterCoolerMeetings.com. It might be a little slow to load, if you check it out.

[00:37:40] SY: That’s awesome.

[00:37:41] MS: It’s on the free plan, so that dyno has got to work its way up. But that was my first website and who knows, it will be revived one day.

[00:37:50] SY: Very nice. Number four, one thing I wish I knew when I first started to code is?

[00:37:57] MS: Okay. So I’m going to cheat a little bit here because there’s two things that I really wish I knew.

[00:38:01] SY: Okay.

[00:38:01] MS: Okay. One is that code review feedback is normal and good and it does not reflect on your ability as a coder. I used to take feedback so personally because especially when you’re starting out, you put up a PR or a pull request, you basically say, “Hey, you know, here’s my code. What do you all think?” And when they put a bunch of comments on it, I used to feel like, “Oh, I failed.” But that’s not the case. It’s literally the feedback process that every one of us, whether you’re a junior or a senior, we all go through it when we write new code. So that’s one thing I wish I had just known earlier on. And the other thing that I wish I had known when I first started coding was that I will never stop Googling.

[00:38:49] SY: It’s a good one. Yeah.

[00:38:49] MS: It doesn’t matter if you have one-year experience or ten years, you’re always going to be Googling. I remember when I was first starting out, I thought, “Okay, I’m going to be Googling in like the first, one, two, three years.” But then like after that, “Oh yeah, I’m going to set. I’m going to be able to like do this stuff in my sleep.” No, that’s not the case. Like technology changes, everything changed. You don’t memorize syntax. So you’re going to be Googling the rest of your life and the sooner you embrace that and you just get really good at it, the better off you’re going to be.

[00:39:21] SY: I think one of the things that I wish I knew when I first wrote a code is that Googling is a skill.

[00:39:27] MS: Oh, it definitely is.

[00:39:27] SY: Like in and of itself because you get better at it, like you get so much better at Googling things the longer you’ve been coding.

[00:39:34] MS: I 100 percent agree.

[00:39:36] SY: Yeah. Yeah. Well, thank you so much, Molly, for joining us today.

[00:39:39] MS: Yes. Thank you so much for having me.

[00:39:48] This episode was edited and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.