#84 Molly Struve, an aerospace engineer trading in SRE
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Molly Struve 0:00
Do what sounds interesting to you do what you love, do what your heart wants to do. And in my opinion, the rest just works out. And it was a winding path. But it all worked out in the end and now I'm doing something that I truly love. And you know, every day I'm excited to get up and do the work that I do. And I can't I can't imagine, you know, having a job where I didn't enjoy it.
Tim Bourguignon 0:34
Hello, and welcome to DevJourney, the podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today, I received Molly Struve. Molly is the lead Site Reliability engineer for the blogging platform dev.to. During her time working in the software industry, she has had the opportunity to work on some challenging problems, including scaling Elastic Search sharding MySQL databases and creating an infrastructure that can grow as fast as a booming business. When not making systems run faster, she can be found fulfilling her Need for Speed by writing and jumping her show horses. Molly, welcome to dev journey.
Molly Struve 1:18
Thank you for having me, Tim.
Tim Bourguignon 1:20
So let's go back all the way back there. How did the first your first steps into the T word look like?
Molly Struve 1:26
Yeah. So basically, it all started for me back when I was in high school. That was kind of my first introduction to programming. And I enjoyed it. I liked it. But you know, I didn't, I didn't like grab on to it and become obsessed with it like some people do right away. So I went to college, and when I went to college, I thought, okay, I want to do engineering, maybe programming. My dad was a, you know, computer science major. So let's do that. So I enrolled into the introduction to computer science class. And as I taking this class, the guy who lives next door to me is taking the intro to aerospace class. And literally every day he's coming running over and he says, hey, guess what I could do? I could build a rocket, or Hey, guess what I get you, I get to build a parachute. And so I'm thinking to myself, that sounds a lot more fun than typing on a computer. So at that point, I literally changed into aerospace engineering and ended up with a degree in aerospace engineering. I'm lucky Luckily, kind of all engineering degrees have the same foundation. So I was still able to get some good programming foundation. And then after college, I spent two years working as an options trader, because that's kind of the family business and near the end of working there. It was the time when all of the excitement was happening in silicon Valley you had Facebook and Instagram and all these companies were really starting to like change the landscape of the internet. And so that was the point when I said, You know, I kind of want to go back to my engineering roots, betting on the stock market is fun, but I want to go back and build something, something and so at that point, I quit my job. I spent three months doing the Michael hartel tutorial to teach myself engineering and you know, software web development. And then after that, I ended up getting a job and internship in the software engineering world and the rest is really history after that.
Tim Bourguignon 3:37
Wow, what a start, let me see if I got this straight. So you started with cs 101. But bubblesort and paper wasn't as fun as building rockets. Exactly. So you swept out to to aerospace as major then graduate graduated as an aerospace engineer, didn't start in aerospace, but go into option trading, did that for a while? And then somehow say no, I want to go back to CS. And it started over.
Molly Struve 4:15
exactly exactly what you know, it's a kind of a windy path. The real reason I didn't go into aerospace engineering, which I think I would have is because I live in Chicago. And so Chicago is not really a hub for those small aerospace companies. So if you really want to work in aerospace, you really got to be in like, the Silicon Valley. You got to be out in like Washington, where those kind of companies are. And so that's kind of the reason why I didn't do aerospace engineering is it just just wasn't convenient given my location. But yeah, and so then I went to Options trading and then found my way back into, you know, software engineering, and I know when I tell that story to a lot of people They kind of are taken aback like, wow, you were really all over the place. And so what I tell people is, you know, I say, first of all, all the engineering, all the different types, engineering, they all really have the same core discipline of problem solving. So you're still getting that good problem solving education. And on the other hand, as well, I also say, you know, what, do what sounds interesting to you do what you love, do what your heart wants to do. And in my opinion, the rest just works out. And it was a winding path, but it all worked out in the end, and now I'm doing something that I truly love. And you know, every day I'm excited to get up and do the work that I do. And I can't I can't imagine, you know, having a job where I didn't enjoy it. And I think that's kind of what drove me when I was doing options trade. And as I kind of stopped enjoying it, and I decided, you know what, this is overhear sounds more interesting. And so the fact that I just kind of kept following my heart in a sense, which totally sounds corny, but I ended up everything worked out. And I think that's kind of some advice I give people when they're just not quite sure what to do. My advice is, you know, if you're not happy, like, look for a change, look for something that's going to make you happy life, as my mom says, life is too short to be unhappy. Amen.
Tim Bourguignon 6:28
Can you put some words on what you were after? In all these jobs?
Molly Struve 6:34
So really what I was after when I went back, so as I said, the options training was really because it was the family business. Um, it was kind of i'd intern there and it was kind of the expectation like, that's where I need to go and try. I think everyone kind of, you know, a lot of people who grew up in families with businesses and stuff. There's always that expectation that the kids are going to go into the business. So, that's kind of what drew me to that path. But you know, being the person I am, I wasn't just gonna stay in there just to stay in there. And, and, you know, trade options. And so, at the time, my husband thought I was absolutely crazy to give up, basically, you know, the most job security ever, like I was guaranteed a job for the rest of my life to switch into this field that I hardly knew anything about that there was no there was no guarantees, I was going to start from zero. But despite the fact that he thought I was a little crazy, he still supported me and he, he knew that I would go after it, you know, full bore and that I could get it done. And so, so anyways, he supported me and you know, I kind of went after it. And really what I was looking for was the ability to build something again, I think trading stocks on the software or trading stocks in the stock market. You're you're literally Just betting on what's going to happen every day. And to me, that wasn't very fulfilling, I want to go back to, to building stuff, just, you know, building tangible things where you can point to that and say, Hey, I built that, that's making the world a better place, or that's helping people's lives, you know, in this way. And that's something that when you're getting that engineering degree, especially in college, you're constantly building stuff. That's literally the whole curriculum is around building and problem solving. And so that's really what I was craving when I decided to make the change back to software.
Tim Bourguignon 8:35
I've always been the the creative and the builder type.
Molly Struve 8:39
I don't know about creative but I'd say I don't I'm always been the builder type for sure. When I was younger, I was always out in the backyard building forts. My dad at a very early age, he taught me how to you know, use all the power tools so I would you know, I'd be signed would and screwing stuff together and building Laura knows what always building something and he taught me how to so I'm definitely one of those people that likes to be self sufficient. And so thankfully, I, you know, I was I was brought up to, to learn how to do all those things. And that kind of drove me towards engineering. It's literally taking all those simple, you know, all those kind of skills that I learned younger and then just expanding them to different mediums.
Tim Bourguignon 9:26
That makes sense. Makes sense. I'm coming back to it. How would you describe your your IT skills just before you made this web from from option trading to going back into into computer science?
Molly Struve 9:39
Yeah. So at the time, the basically what I learned when I was in school was Java. So I had the basic back and concepts of Java, that language, just kind of the basic software engineering concepts, but like, very basic as I as I said, I'm We would use coding to solve problems in aerospace. But like I said, very top level just, you know, high level algorithmic stuff. It wasn't architecting architecting systems and things like that. And so when I made the transition into web development, Java is not a heavily used web development language. And so I literally at the time, I think I googled what the most common languages were in web development. And of course, Ruby on Rails popped up at the time. And so I said, Okay, I'm gonna learn Ruby and Rails, and that's how I'm gonna get a job in web development.
Tim Bourguignon 10:43
Did you explicitly wanted to, to go into web dev?
Molly Struve 10:46
Yes. So that was, you know, that was like I said, all this cool. stuff was happening in San Francisco at the time you had the Facebook, the Instagram and web development. Like the most tangible path for a software engineer at the time, because you had all of these startups coming up, and it just seemed very exciting. And so that's why I thought, okay, that's what I want to do. I want
Tim Bourguignon 11:15
to grab grab into the future and talk about your, your current job, your site reliability, which is kind of the opposite of what I would picture in web development. But that's a bit too far. We're going to come to that in a minute. So how did how did you get to to start this path again? So you mentioned you mentioned a tutorial. And yeah, how to beat yourself, which tool did you use? How did that look out?
Molly Struve 11:42
So it's a pretty kind of famous tutorial in the Ruby and Rails community. It's the Michael hartel tutorial, and Michael Hartle is a brilliant Ruby developer, and he created this tutorial which basically teaches you how to build a Twitter app using Ruby and Rails and it takes you through step by step. And at the time, this was, what, seven or eight years ago, I literally printed out the whole tutorial I actually have, I tweeted out a picture of this at one point, and highlighted all this stuff. I mean, it looked like I was in high school, again, papers out and highlighting and circling things. And I literally spent three months going through that tutorial in building this quote, unquote, Twitter app. But at the same time, I was tweaking that Twitter app to be my own web application, which actually, I called water cooler meetings calm. And that website is actually it still runs. It's on the Heroku free plan. So it's kind of crazy to see how far I've come but I like to refer to it you know, anytime I'm, you know, kind of like down or me I'm discouraged. Like Okay, yeah, go back and look at See how far I've actually come. But literally taking that Twitter app, tweaking it to be this water cooler meetings, calm app, is how I learned and I literally was just three months of, you know, nine to five every day just, you know, just kind of crushed and crushing the code.
Tim Bourguignon 13:18
And after three months, you found a job and has been absolutely happy ever after.
Molly Struve 13:24
Yeah, so basically, I think those three months, and then at the time, there wasn't a lot of these online communities that we see now. So now we have dev dot two, we have code newbies, which is another one. We have a lot of really great communities for beginners, as they're getting started with web development, or software engineering. Those didn't exist seven, eight years ago. And so working by myself became pretty isolating. And literally after about three months, I thought, you know, I'd be really nice to get on a team again. And so I said started, I looked at the one source of jobs Hacker News. Found, found a company in Chicago that was looking for a full time software engineer, which I was far from. But I thought, you know what, let's email them anyways, maybe they'd be interested in an intern with an option to hire. And I knew if I could just get my foot in that door, I'd be set. And so I emailed them and said, Hey, this is how much experience I have. I would love to come in work for you as an intern, and then have an option to hire, what do you think? And they were open to it. And so they brought me in, I showed the small team of three devs. They had the app I had built and they ended up hiring me for a six month internship which then lead to a full
Tim Bourguignon 14:55
time job. That's a nice way to do it. Just be be bold and and try it out. And Some time it works.
Molly Struve 15:00
Yeah. So that's that's definitely advice I try to give people who are looking is always ask Always, always, you know, if you see a company where you think, wow, I really I really like what they're doing I really want to work for them but they only have a software engineering position listed it even if you don't have a lot of experience, email them, you you really never know what they might be open to and it never hurts to ask worst case, they're going to come back and say, You know what, we really need someone with more experience. And now you know, but I it's always worth it to ask because you just don't know
Tim Bourguignon 15:40
how to get through this. The first year as a as an intern first and then I suppose as a developer, Oh, man. So
Molly Struve 15:48
lucky for me, I ended up with a group of three really great guys who were super awesome and taught me a lot but the first year was definitely Oh my god, lots of ups. Send downs and a lot of Holy Holy cow, what did I get myself into? But luckily, like I said, I had this three this this group of guys, these three mentors that really just taught me a lot. And one of the guys I still work with To this day, he ended up we ended up going to the same company afterwards. And yeah, they ended up teaching me a lot. And it was, it was a lot of fun. And I think after that first year, there was no looking back. I knew I had made the right decision at that point because I was just in love with what I was doing
Tim Bourguignon 16:38
what made dues, dues, mentors, special all the relationship you had all the way they taught you what would characterize this this relationship,
Molly Struve 16:49
they were always one of the big things they were always super encouraging. Um, you know, especially when you're when you're a young Dev and you For example, You put up a PR. So you, you you fix a bug or you put up some code, and you get a bunch of feedback Well, when you're when you're a young dev starting out, and you see that feedback come, at least for myself, I always thought that meant, oh my god, that was horrible code I just wrote, like, I got so much feedback. And they really broke it down and taught me feedback as part of the process. It's not, it doesn't mean your code was bad. It doesn't mean anything like that. It's literally part of how we learn and we iterate on code. And so that was one thing they taught me. And it's literally they just taught that through, you know, not only pointing out what I could improve in my code, but also pointing out what I did well, so they'd make sure to say, Oh, this line, this is really great. What you did here, I have a suggestion for what you could do over here to make it you know, just as good. So that was one thing and then another is that they constantly took time to do you know one on one with me. So anytime I didn't understand something or you know, concept was maybe hard to grasp, they would literally just slide over to my desk and they'd be like, okay, let's just we'll do this together. And you can see how this works.
Tim Bourguignon 18:11
What do you think they took out? Personally out of this? They could have brushed over it and say, well, we we have enough work to do. But they took the time all three of them.
Molly Struve 18:20
Right. So I, you know, and I think it's, it's part of a person's character, really, but all three of them as well as the the company itself. It was it was a very small startup, as well as the founders of the company really saw me as an investment. And the best way to capitalize on that investment is to teach me And so rather than seeing me as just someone who's going to get grunt work done, they saw me as Okay, if we invest time and effort into this girl, and we improve her. She's going to be able to contribute Even more to the platform and build even more. And so I think, you know, the whole company kind of had that mindset and which I think was evident in the fact that they agreed to take me on in the first place. And so I think that's something that's really crucial to have. And something that really, when you're starting out, you want to kind of look for in companies, because there are times when you'll go and you can start an internship and you're just there for the grunt work. You're just there to, to, you know, fix bugs. And I was lucky enough that it wasn't that situation it was, we're going to bring this girl in, we're gonna teach her so that she can be just as good as everyone else. And then, you know, now we've got a good software engineer.
Tim Bourguignon 19:44
Do you have a tip how to recognize this in a company you're you're applying for?
Molly Struve 19:50
Yeah, so I think one of the biggest things is one, ask the you know, when you're interviewing, you're gonna probably be talking to somebody senior engineers, some more experienced engineers, ask them how they feel about mentoring, ask them what their mentoring methods are, they should be able to tell you that one, they should be interested in mentoring. And two, they should have some good mentoring habits that they get into things like pair programming things like, you know, helping with PR feedback and giving constructive PPR feedback, things like that. So you really you want to talk to those people that are in the mentoring positions. And then at the same time, if you can talk to other juniors, if there's any other juniors or people at the company who are in the position to be mentored, ask them what their experience has been. Do they feel they're getting the mentorship they need? Do they feel they've really, you know, learned and grown in their roles?
Tim Bourguignon 20:53
To very wise ideas. Thank you. Yeah. I'm trying to think back about my my personal history. And I think I have I've not done that enough. Probably too late in the process.
Molly Struve 21:03
Oh, to mentor
Tim Bourguignon 21:04
no to to ask about it. Oh, yeah.
Molly Struve 21:07
I mean, I was the same way I never asked because I just didn't know. And so I kind of tell people I got extremely lucky. And so but I do think it's something that you have to ask about because if you are young in this industry, and you're, you know, you're a beginner Dev. I have seen it so many times where a beginner dev starts at a company that's not set up to mentor them. And it ends up being a horrible experience and it just crushes confidence, nothing can crush confidence more than if you are beginner dev in a situation where you're not getting the mentoring your meet because all you feel like is that you're behind and that you're struggling. And so that's why it's so important. And that's why I tell people you know, to make sure you ask those questions when you're in an interview. It's it's not Just about, you know, will this company hire me please hire me, please hire me, you have to interview the company, you have to make sure that company
Tim Bourguignon 22:09
is right for you as well. That's true. The interview goes both way. That's that's very wise. So how long did you stay at this company?
Molly Struve 22:18
So the first company ever worked for is a little coupon startup called called aisle 50 doesn't exist anymore. But about two and a half years after I started, they got acquired by Groupon. So the whole team went to Groupon. Unfortunately, the acquisition was more of a talent acquisition and so like the whole team got split up. And anyways, long story short, I lasted about six months there I did not enjoy really working for a big company and being a little fish in a big pond. And so at that point, I ended up leaving Groupon and that's when I joined kind of security, which is where I spent the good portion of the last four and a half years was that kind of nuts really where my software engineering career kind of went to the next level, that's where I found Site Reliability Engineering, and all that good stuff.
Tim Bourguignon 23:12
So so let's go there. What to what kind of position to apply for
Molly Struve 23:17
when I originally applied it was just for a software engineering position. And at the time, Canada was about 30 employees. And I think the tech team, we had about seven engineers at that point. So I applied for a software engineering position. I was actually more junior than they thought they wanted, but once again, they took me out anyways. And so as I was working at Kenna, basically what happened and kind of took me into the cyber liability stuff is I was working and a couple of the senior engineers ended up leaving. And so one of the big things the senior engineers were in charge of was a database called Elastic Search. So When they left, I kind of saw that as an opportunity to grab a hold of something big a cornerstone of this platform and take ownership of it. So I had never worked with Elasticsearch before. But I said, Okay, we're just going to learn everything we can. So I went to trainings, I read docs, I, you know, did tutorials, the whole shebang, and ended up teaching myself everything I need to know about Elasticsearch and literally just owned that piece of the infrastructure. Me and one of the other guys took a hold of this and we ended up architecting, our Elastic Search cluster, to the point where it was able to scale from holding a few hundred million documents to right before I left, we had well over 5 billion and it would process you know, hundreds of millions of them a day. And so taking ownership over that back end Cornerstone piece of kind of platform is what then led me to start right liability engineering because when the team grew so big that it was time to break up the Dev, the single dev team into multiple smaller dev teams, our VP basically came to me and said, hey, you're kind of already doing site reliability. So what do you think about making that your full time job? And we'll, you know, move you over to a site reliability team? And of course, I said yes, because I was loving what I was doing. And that's how I ended up in Site Reliability Engineering,
Tim Bourguignon 25:30
I think now's a good time to to define it. Maybe you could you could you give us your definition of it.
Molly Struve 25:35
Yes. So Site Reliability Engineering, there's, you can get so many definitions. for it. Some people refer to it as DevOps, but Site Reliability Engineering, to me is software engineering, but with the focus on reliability of the system and performance of the system. And so when people ask what makes a good site reliability engineer. My common response is someone who doesn't just look at the code and just see the code they don't look at, you know, a file and just see what that file does. They're someone who can kind of take a step back from the code and look at the system as a whole. How does this code interact with our database? How does this database then interact with our servers? How do all these pieces you know, fit together? And I think that's what really makes a good site reliability engineer is someone who can conceptualize the entire system. And then you make the decisions about what you code, how you code, database decisions, etc. Based on keeping that entire system performing at its best.
Tim Bourguignon 26:51
Do you make a difference between SRP and something like system architecture, or system system architect job That would be the definition I I had in mind before.
Molly Struve 27:03
Yeah. So system architecting, I've always kind of thought of is more of an operations role. So you're working less with the code, and you're working more with infrastructure. So things like servers, etc. I think as a site reliability engineer, first and foremost, you're a software engineer. So you look to solve problems with code, where I think when you get into some of like the infrastructure system sides, DevOps, I think, those kind of jobs and those roles are more using what is on the infrastructure side and less, they're less about the code,
Tim Bourguignon 27:42
okay, made sense. I want to be nasty and try to be polarizing and see words. When I hear this definition, I kind of hear non functional requirements. And that's always something that I'm fighting with, with my software teams. Yeah. Is to get them to I own the whole system and not just the features, but also the non functional requirements of scaling the performance and making sure that that they take care of it from the get go. And when I hear that there's someone like you taking care of it. That's kind of going against the empowerment that I want to, to to give my teams.
Molly Struve 28:23
Yeah, so that's, that's actually a great point. And that's something we were very aware of at Cana. So as I mentioned, when we got so big, we had to break off in, you know, break at the big team into multiple teams. When I eventually left Canada a couple months ago, we had four different engineering teams. And then we had one small SRU team with three people on it. So obviously, the rate at which the developers are developing stuff is a lot faster than you know this little SRU team can keep up with. So one of the things we did was, we did Rotation where one developer from a team or two, depending on how we, you know, depending on when we did it would come over and join the essary team for, you know, two to three months. And literally what our goal with that was, was to introduce the SRP mindset, because like I said, I really think it's a mindset of, you know, thinking about performance thinking about when you make a code change, what happens if this code is hit a million times. And so we did that in order to, we would then give these developers the essary mindset, and then we'd send them back to their dev teams. And it was awesome to see them go back. And when a PR would come up, rather than the essary team having to go look at it and say, you know, hey, this doesn't look like it's a very performance, db query. You know, what do you think about changing it, those who we had sent back kind of had that mindset and would take that to their team. And so that helped the devs. Learn more about the essary mindset and then empower them to own it themselves. I have a big
Tim Bourguignon 30:07
smile on my face. That's exactly what I was hoping for. Yeah.
Molly Struve 30:11
Hundred percent agree, you know, the essary team, we want to build tools and stuff to help developers. And so, you know, you can't just have the team looking over everything because code goes out too fast. And you have a big dev team. So it's definitely about empowering the developers and teaching the developers so that they can have that mindset as well.
Tim Bourguignon 30:31
So So it's been a few years now that you are working necessary. What gets you gets you motivated to working with it every day, or after? Three, four years now?
Molly Struve 30:41
Yeah, so now it's probably I think it's been three years coming up this January. And honestly, it's, it's finding those small performance improvements that just propagate through the entire system. So you, you look at one file, and you see that you're making In a database hit that you don't need. And you literally add one line of code, one little guard clause to prevent that database hit from happening. And you deploy it. And all of a sudden performance across the board, you know, improves immensely. And it's finding those little performance of ruins is just when you see it. Oh, it is the most fulfilling part of my job by far, making stuff fast, making things go faster than people think they can. It's it is the best.
Tim Bourguignon 31:32
I interviewed a few months ago, Katrina when she's working in the core system of GitHub, and she described exactly the same the same behavior that searching for for something and searching for hours, hours and days and days. And finally making one small change on one line of code and sparing the I don't know maybe multiple hundred thousand dollars for the car. Yeah. Having big smile just about that.
Molly Struve 32:03
That's that is. That's how it happens. You You spend days in the trenches. But when you come out you have this, you know this performance boost. It's I mean, it's like it's like a kid on Christmas, literally, I'm always running them or running over to my coworker saying, look at this. Look what I just found. This is amazing. So it's a it's that's what I that's what I love about Site Reliability Engineering.
Tim Bourguignon 32:27
I understand I understand. Switching gears a little bit. Would you mind introducing delta to to the listeners of the podcast? I'm not sure they will aware of that.
Molly Struve 32:36
Great question. Yeah. So dev two is a blogging platform. So you can kind of think of a platform like medium. But the big difference is that the platform has an amazing community of software engineers. So all the blogs are focused around tech, software engineering, things like that. So you you kind of know what you're going to get there. And the community is just awesome. It is super supportive. They, they take the community very seriously. And so they monitor it, they, they make sure that, you know, there's a code of conduct that everyone abides by that code of conduct. So it really makes it a great safe place to, in my opinion, you know, really get into the software world, get into blogging, learn stuff, ask questions, and really what they're trying to do bringing all this kind of information to more and more people and doing it in a very approachable and friendly way is is what drew me to death.
Tim Bourguignon 33:45
Tell us the story. How did you discover that? Did you start as a as a user and then took a job over
Molly Struve 33:51
it? Exactly. So I started as a user, which is actually I literally just had my one year you know, anniversary of being on the platform. So last year, I started blogging. So I started speaking as our blogging last year and kind of started exploring, you know, content creation, and just sharing all this knowledge that I gained over my years being a software engineer. And so I started using dub dot two and exactly what I just described, what I found was a, you know, an inviting community and their, you know, their mission of sharing knowledge in an approachable, friendly way really spoke to me and so literally what I said to myself was okay, when kind of gets to the point where it's too big, this is the company I want to work for next. And so I had that in the back of my mind. Fast forward to, you know, over this past summer, I ended up getting an email from the founder of dev saying, Hey, we're in the market for a site reliability engineer. What do you think? First I thought, No, no, no, no, no, no, no too early, too early. This is not how I planned it, because that's that's kind of how I am. I'm all about like my plan, I got my plan. And so long story short, I kind of went through the interview process. And I honestly, I was extremely happy with Canada and I still love Canada. I still tell people to go work at Canada, because it's an amazing place. But it really wasn't up until I actually told kind of that I was going to move that I wasn't even sure if I was going to do it. But the opportunity to literally take what I did it kind of so kind of now is close to 200 people, the platform is huge. Um, and so I what I saw a dev was the opportunity to do what I did at Cana and do it again. So like, go back to square one small platform and, and build it and you know, support it and you know, do that all in a way So that when this platform explodes, as the users, you know, grow and come to it, it's going to be ready. And it's going to be in a position to be performant and reliable. And on top of that, it's a platform that I just firmly believe in their mission. And so all of that kind of combined is what made me say, Okay, this is, you know, I, I wasn't ready to make this leap. But
Tim Bourguignon 36:24
this is the right thing to do right now. And so this has been a year now. It's only been a few months. Okay, so was this summer?
Molly Struve 36:31
Yeah. Is still relatively new. I've been at dev for since a mid October,
Tim Bourguignon 36:36
so almost two months. Okay. Okay. So with tickets through these two, two months, what are the dyes and the lows? Oh,
Molly Struve 36:44
so it's honestly it's been a lot of highs. So I came in and right off the bat there is there's things to do. So one of the things that I talk a lot about, I actually gave a few talks this year, on is monitoring. And so one of the mistakes that you see a lot of smaller companies make. Not even small companies, a lot of companies in general, when they're doing monitoring is they use all these different tools. And so you come in and you say, you know, how do I see the status of your application? And they throw five URLs at you, you're like, Okay, well, you have to go to five different websites. And you're like, Okay, this website showing me the request to this API, and this website, showing me how our workers are doing and this website showing me our, you know, our server status. And so one of the first things I you know, I did come in was just kind of consolidate that all and so, so projects like that, we're, you know, we're moving our databases to new open source databases. That's, that's another huge thing about the the dev platform dev.to the community, the code is completely open source. And so I think that's, that's truly awesome because everyone can See everything we're doing. So as we're making these switches to more open source services like Redis, Elasticsearch, it's going to be something that that others can use and learn from. And so that's kind of just like another cherry on top of, you know, making all these changes. But it's, it's been good and I'm, I'm really excited that I get to come in. So right now the dev team is we've got about 13 people. And so because I came in so early, it's it's kind of relaxing because i'm not i'm not rushing to keep up with, you know, a massive user explosion already. It's I can kind of lay the groundwork so that when things really ramp up or when you know, the next traffic spike happens, we're ready as opposed to like trying to play catch up.
Tim Bourguignon 38:49
Does you experience a drawback or failure? Already?
Molly Struve 38:52
Oh, yeah. Oh, I've already I've bribed broken multiple things.
No, no massive failures, but I I mean, there have been times when I pushed out code and oh, oh, that's broken that we need to roll that back. And that comes with a territory. And it comes with learning. So one of the things we're doing right now we actually just finished is we're moving from mem cache, which is a data store, key value data store, to Redis. And I didn't know a lot about mem cache, or how it was integrated with rails. And so let me tell you, I broke a few things. And I learned a lot. Now, you know, because of that, now, I know a lot about mem cache and how it works with with rails and the framework. And, you know, I'm really a big proponent of when you break, things like that, that's how you learn. And so so yeah, of course, I've broken a few things already. But I've also learned a lot which is, I don't know, to me, that's even more exciting. Do you
Tim Bourguignon 39:52
approach the approach this new job differently than you did the ones before? I mean, from your mindset, The way you you entered the workplace or something like this,
Molly Struve 40:03
definitely. And I think all my jobs in the past where I kind of had this mindset, like, Okay, I'm going to come in, and I'm going to do what they tell me to do. I, you know, didn't have a lot of experience, I was literally just there to learn, absorb and do the best work I could, coming into dev being at this point in the career where I am, I'm a lead Site Reliability engineer, I have, I feel this, you know, sense of ownership that, you know, it's, it's my duty to come in here, and help lead this team and lead this website so that it can be the best that it can be. So there's, you know, definitely a lot more expectation in my mind that I come in and rather than being passive and sitting back and waiting for someone to tell me what to do, I'm the one that's come in saying, you know, okay, this is what we should be doing here. This is what we should be doing here. What do you think about this? And so, you know, being the one to come in with the ideas, it's it's definitely a little bit of a transition. And at first, every time I was thought about something, I would make sure to get, you know, input from everybody. And it took a few times of, you know, better founder saying like, yeah, Molly, like, definitely go with that, like, you should roll with that. Um, so it's definitely it's a mindset shift. getting to that point where you're kind of the one like, Okay, I'm, I'm kind of in control, like, let's make these decisions and and get them done.
Tim Bourguignon 41:34
This is your first leadership position.
Molly Struve 41:37
So I was in a leadership position at Cana. Um, so it's, you know, my second leadership position, but I've only kind of been in the lead position for almost a year now,
Tim Bourguignon 41:48
did you have difficulties going into management and individual contribution going back and forth between the two.
Molly Struve 41:56
So luckily, at kind of because the team was so special, When I moved into the lead role, I didn't have a lot of management responsibilities. So you had I had one on ones with a team members, those small checkins. But beyond that, there was another director above me who kind of helped do most of that the management work. And so I was really able to focus on leading technically, which is what I love. So being able to sit down, be able to mentor and teach people is that's really what I enjoy about leading a team. And so I got to do a lot of that kind of, I'm sure as the Dev, you know, as dev grows eventually, you know, I'll have to be further away from the technology but I don't see that happening for for a while. So I've got I've got many more years being very tactical ahead of me, I think
Tim Bourguignon 42:51
that's perfectly fine. That's actually a whole you should be, um, but you mentioned mentoring. So how is your mentoring? How do you act as a mentor.
Molly Struve 43:00
Yeah. So when I'm mentoring someone, one I love, you know, I love being able to kind of sit down and walk through problems with them. I think I think one of the most beneficial aspects when you have a mentee is for them to just see your thought process and and how you walk through stuff. I think a lot of times mentees look up to some of us, you know, the senior engineers, the lead engineers, and they kind of think we have it all figured out. And I remember I had this one instance, where we had a bug, and I did not know where the bug was coming from. So I was like, You know what, I'm gonna jump into that. And someone said, Oh, I want to I want to investigate that with you. And we go, Okay, sounds good. So they, you know, went to investigate with me and their first thought was like, okay, where are we starting? What are you doing? I was like, You know what, they're like, what's wrong? God, I Honestly, I don't know, like, so what are we gonna do? Like, I'm probably gonna read some logs. They're like, what are you looking for? Like I don't even know. It was kind of an aha moment for them where they realize like, when a bug or something really, you know, a really nasty bug pops up a lot of times, we don't even know where to start. So literally, we just go to these tools that have helped us in the past, we go to our logging, we go to our monitoring, and half the time, we're not quite sure what we're looking for, but we're gonna pull that, you know, pull them open and say, You know what, I'm looking for some sort of anomaly that looks like this or like this. And so then being able to see kind of how we walk through this problem solving process. I think that's one of the most valuable experiences. When you're mentoring someone. I think, you can teach code, you can teach good architectural principles, etc. But seeing that kind of problem solving process, I think, is what One of the most valuable aspects when you're mentoring a person, so really, you know, my advice to mentors is just like, be open about everything. You know, when you don't know, when you're jumping into loss, like, tell all those pieces, they're not, they're not pretty, you're stumbling around, you know, like, you're a junior at that point, cuz you're like, I don't even know what I'm going for here. But like, that's, that's what they need to see, because that's part of the process. And so, you know, and then as you do it more and more, then you start to figure out what you're kind of looking for. And then that's how you get better. So that's one thing I always like to do when I'm mentoring. And then the other thing is always give more positive feedback than you think the person needs. And that's something that I've just seen, I've worked with developers, where I thought they were brilliant. And I remember gain feedback that about, you know, from the one point saying, you know, how do you you know, how do you feel it's going etc, and was taken aback when they weren't sure if they were keeping up, they weren't sure if they were doing a good enough job. And from my perspective, they were blown me away. And so seeing that kind of disconnect, where the developer isn't sure if they're doing a good enough job, but on my end, I think they're absolutely crushing it, I make sure that I am, you know, give praise, overly what I think is almost too much. And that's usually that's usually enough, when you're starting out because you need that extra confidence boost, because Cody in itself can just can slap you down. And so I think, you know, making sure to give the positive feedback when you when you review a PR, if you're reviewing a senior's PR, it's fine to just go in and you know, maybe point out some stuff they need to tweak. But if you're giving feedback on a PR for someone who's just starting out, you have to go in and list the good points. You have to say you know what this class name thought that was a great name. This the way you architected this method That was that was fantastic. So you really, really focus on the positive feedback,
Tim Bourguignon 47:05
because it's very true. There's there's a say something like when negative outweighs four or five positive or something like this.
Molly Struve 47:12
Exactly, exactly. Yeah, I know. I know what you're referring to.
Tim Bourguignon 47:16
I'm not sure what to correct wording is right. So something like this. If you were to hire someone tomorrow, what would be the first advice you would give him?
Molly Struve 47:24
So advice on getting hired or advice on like, getting the job done?
Tim Bourguignon 47:29
I'm starting a new team.
Molly Struve 47:31
Oh, starting new, um, take it all in. So especially when you're starting a new job, and I, I even had to be reminded of this. You're not expected to contribute, at least in all the healthy companies that I've ever worked at. When someone starting out there's there's no expectations. Don't, don't put those expectations on yourself. Sit back and just absorb everything you can ask. You open your first PR as you start contributing code, just really take in everything that's going on. And that's kind of how you figure out the rhythm of the dev team that you're that you're joining. And that's how you end up soaking in, you know, new knowledge, etc. So don't my my best advice is Yeah, soak it in and don't put any expectations on yourself because there probably isn't expectations from anyone else. They expect you to come in and expect you to be doing a lot of learning anything beyond that, you know, is a bonus.
Tim Bourguignon 48:35
Amen. But dealing with this monster inside our heads is still worse.
Molly Struve 48:39
Oh, it is. It's
Tim Bourguignon 48:41
true. I'm Molly, thank you very much for all these advices it's a it's absolutely fantastic.
Molly Struve 48:47
You're welcome. Thanks for having
Tim Bourguignon 48:48
me. Always a pleasure. If listeners wanted to continue this discussion with you, where would the best place be?
Molly Struve 48:55
Yeah, the best place is probably Twitter. Molly underscore screwby. My DMS are always open so feel free to DM me or even on dev.to m slash m screwby. Feel free to look me up there and in messaged me on there too. dams are open on there as well. So either either platform, I am always I always love hearing from people I love chatting with people. So definitely don't be shy to just shoot me a DM and just just say hey and and ask me any questions that you might have.
Tim Bourguignon 49:29
Amen. Do this people do it? Anything coming up on your plates in the next month that you want to plug in.
Molly Struve 49:36
So lucky for me the winners gonna be kind of quiet because I go when I show horses but coming up in April, I'm very excited to be going to the lead dev conference in New York. I'm going to be speaking there about on call and making a good on call rotation because that's something I know a lot of developers don't like, but I'm going to give a talk on how To make it less painful for everyone, so super excited about that.
Tim Bourguignon 50:03
I'm looking forward to hearing about it. Thank you very much Molly. That's been bless. And this has been another episode of developer's journey. We will see each other next week, bye. All right, this is Tim from a different time and space with a few comments to make. First, get the most of these developer's journey by subscribing to the podcast with the app of your choice, and get the new episodes automagically, right when the air. The podcast is available on all major platforms. Then, visit our website to find the show notes with all the links mentioned by our guests, the advices they gave us, their book, references and so on. And while you're there, use the comments to continue the discussion with our guests or with me, or reach out on Twitter or LinkedIn. Then a big big THANK YOU to the generous Patreon donors that help me pay the hosting bills. If you have a few coins to spare, please consider a small monthly donation. Every pledge, however small counts. Finally, please do someone a favor, tell them about the show today and help them on their journey.