Career Paths in Tech
There are so many different paths your career can follow in the tech industry. There's frontend, backend, or even full-stack development. You could also be a software engineer, quality assurance engineer, UX engineer, manager, developer advocate, or something else entirely!
Shout out to our sponsors for supporting the LadyBug Podcast!
Sanity.io is a platform for structured content that comes with an open source editor that you can customize with React. Sanity.io also comes with tooling that lets you build with structured content in React, Vue, and other frontend technologies like Svelte. It also has powerful APIs for reading and writing so that you can use the same content across any device, channel, or product. You also get powerful APIs for querying your content, you can even listen for changes in real-time, and use the write APIs to patch and make new documents from code. You can get started for free on the standard plan, and add a credit card to pay as you go for usage over the generous standard quotas. If you need advanced features like SSL and Single-Sign-On you can find all the prices and details on Sanity.io's fully transparent pricing page. Listeners of the Ladybug Podcast get a extra special plan with double the usage. Go to sanity.io/ladybug or use "ladybug" where you fill in the coupon code.
Are you a developer looking for your next challenge? Meet Shopify. We’re on a mission to make commerce better for everyone - but we do things a bit differently. We don’t tell people how to solve problems - we give them the tools, trust, and autonomy to build new solutions. We don’t work alone - we leverage the diverse perspectives across our teams in everything we do. And we don’t have all the answers - we’re big enough to tackle problems at scale but small enough that we haven’t figured them all out. If you’re a builder at heart who wants to solve highly technical problems. If you want to take all of your life experiences and apply them to a blank canvas. Or if you want access to really powerful tools - Shopify is the place for you. Visit shopify.com/careers today.
We want to tell you about the JAMStack Conference, happening Oct 16-18 in San Francisco. So what’s the JAMstack? Chris Coyier got to the heart of it when he said the explosion of new APIs and tools are providing front end developers with full stack superpowers. We call this new approach the JAMstack.
Hear from Chris, Mandy Michael, Katie Sylor-Miller and more at this two-day event covering topics from web performance to static site generators to modern build tools and workflows. On day three you'll have the option to join hands-on workshops about serverless functions, front end adventures and more.
Podcast listeners can save 10% using the discount code “ladybug” when you sign up. You are also encouraged to apply for a diversity scholarship by August 23rd. Hurry—the last two JAMstack events sold out. All the details are at JAMstackconf.com
1:47 - Frontend Developer
9:16 - Backend Developer
12:51 - Full-stack Developer
20:15 - UX Engineer
25:16 - Dev Ops
27:50 - QA Engineer
30:37 - Software Architect
33:59 - Developer Advocate / Evangelist
36:38 - Open Source Maintainer
41:30 - Manager
47:10 - Wins!
- Listener Win - Katie Brouwers - started her own freelance business and is close to landing her first client
- Lindsey - Started making egghead videos again
- Emma - Went on her honeymoon
- Ali - Went Camping with Blair
- Kelly - First open source contribution accepted
- LinkedIn Jobs
- CSS Tricks Job Board
- The Great Divide
- Developer Avocados
- Developer to Manager: A Survival Guide
Help us out
Ali [0:00] There's so many different paths that your career can follow in the tech industry. You can be a software engineer, a QA engineer, a UX engineer, manager, developer advocate, and even more. So in this episode, we're going to explore a lot of those paths. And let's go ahead and get started.
Kelly [0:21] Welcome to the Ladybug podcast. I'm Kelly.
Ali [0:24] I'm Ali.
Emma [0:25] I'm Emma.
Lindsey [0:26] And I'm Lindsey, and we're debugging the tech industry.
Kelly [0:34] I want to put in a quick shout out to one of our sponsors. sanity.io is a platform for structured content that comes with an open source editor that you can customize with react. sanity.io comes with the tooling that lets you build structured content and react view and other technologies like spelt. It also has powerful API's for reading and writings that you can use the same content across any device, channel or product, you also get powerful API's for querying your contents. And you can even listen for changes in real time and use the right API's to patch and make new documents from code, you can get started for free on the standard plan and add a credit card to pay as you go for usage over the generous standard quotas. If you need advanced features like SSL and single sign on, you can find all the prices and details on Saturday to is fully transparent pricing page listeners of the Ladybug podcast, get an extra special plan with double the usage, go to sanity.io slash Ladybug or use Ladybug wherever you fill in the coupon code. So before we jump in, I think it's worth noting that we will not be discussing salaries for each of these positions. It goes without saying that what you make in San Francisco is going to be different than what you make in that village in Iowa with a population of 12. So with that said, let's get started. So we're going to start things off with Lindsey talking about what a front end developer does.
Emma [3:37] So just to your point, you had mentioned Chris Coyier article about the great divide. And I think you had a lot of valid points about how it seems like people are almost having identity crises within within front end development. And we'll get more into this when we talk about UX engineering, because I think that this is something that has spawned out of this great divide and a sense, one comment I just wanted to make is that I'm going to be very Curt here. I personally hate boxing people in to a specific job title as being there, the entirety of their skill set, right. So often, we'll see front end developer and then just assume that they don't have any knowledge on databases or, you know, even lower level technologies, or we'll see back a developer and assume that they know nothing about design. And I understand the importance of having job roles. But unfortunately, that seems to box us into a specific skill set. And that's pretty unfortunate, right? Like, do you know how many designers I have met who can actually code it were who were coders and their past life, and how many front end developers who have a vast knowledge and design so I, I don't know what your opinions on this are. But I just hate that these these titles, boxes into having a specific set of skill sets.
Kelly [4:47] I completely agree. And also, it can appear limiting on your resume as well, when you're trying to find a new job when they're, you know, somebody may review your resume, like you have experience, maybe working in, you know, Python or whatever. But your job title says you've been a front end engineer all of your life. And you have to prove yourself in other ways. And I mean, that's also why it's important to you know, find side projects and build out things on GitHub been know, whatever, wherever you want to, you know, host all that stuff. But all that just said, Yes, I absolutely agree with you.
Ali [5:21] Yeah, I think that I can talk about this a lot. Because as we're going through this, I have held a lot of these titles today, some officially some artificially. And my career hasn't been that that long, I think I got my first paying job in tech like six years ago. So all that to say is that you can definitely jump around, you don't have to lock yourself into one title. And those titles are going to look so different at different places, like what's called a developer, some places as a software engineer, other places as a front end engineer, other places like these things don't necessarily carry over super well, from company to company, they're going to have different silos and different titles everywhere. And also, I think that if you're working at early stage startups specifically, or if you're a founder or something along those lines, you're going to be wearing a lot of hats. So definitely the title. So you don't you don't fit in super well there.
Emma [6:18] One thing that really bothers me and again, I'm going to be very frank about this, because I have strong opinions on this is when companies put out an application, or a job posting for, let's say, for any developer, and within the required skills, they asked you that you have SQL or like sequel experience, and like you've worked with Python, and MIPS assembly language, and like these unrealistic job requirements, two points to this one is you should never be afraid to apply for a job, if you don't meet all of the requirements, almost no one does. And to please stop trying to, you know, get a deal on specific skill sets by listing it under a job role that's typically paid less. So let's say you're hiring for a UI developer, but you want someone with like SQL and back end skills, please don't do that. Because then you're you're shortchanging people on their value in their worth, right? If you want someone that can work the full stack, they should be compensated fairly. And that's something that I'm very strongly, you know, I have a lot of strong feelings about because I think it's easy for companies to put labels on us and to just look at us as assets. And realistically, we're all people with family support, and we should be compensated fairly. So if you decide to go with a company who wants you to work, you know, across the stack, and you've got a very renowned set of skills, like make sure that you're being compensated for that.
Kelly [7:33] I agree with that. And also just an additional note there. So for larger companies, who maybe have an external HR team who are listing these positions, so they have recruiters, please educate them on what these technologies are, that they're, they're listing for, you know, how many times you've come across a job description that asks for, like, 18 years of swift experience, you know, something that hasn't even existed for that long. So it's really important to also educate those who are trying to find somebody for that position to fill. So you know, there has to be that open line of communication, or else you're never going to find somebody who's a good fit.
Emma [8:07] And just to the recruiters, I've had so many great recruiters and I think that your job is extremely hard, right? I'm not going to play that down. But what I would say justice, to Kelly's point, please don't like cold email, people who have no experience with, you know, let's say cobalt, for example, and say, you'd be a perfect fit for this Cole ball roll. Also, like if you don't, aren't interested, like, can you for this on to someone who is? That's not how you would get quality candidates, right? Like if you're going to reach out to people like, don't tell us that we're a perfect fit. If we've never worked with it. That's just my personal opinion, right? I'm, maybe not everyone agrees. And that's okay. But if you're recruiting emails are not getting traction, look at your wording, right? Are you reaching out to the right candidates, and also in your initial email, don't try to make us you're special. But then at the bottom, say, if you're not interested, pass this along to someone who is right, like make those personal connections. And some of the best recruiters iPad have done that, where they've actually talked to me like I am special, or I am a person and not just an asset to be acquired.
Kelly [9:07] Agreed. It's been a little bit of a long but important tangent. But let's talk about back end development. Ali, you want to do this one?
Emma [10:52] Oh, yeah. Yeah, I learned in school, I learned Java. And we did MIPS assembly language, or like, I actually, like hardwired a breadboard with RAM, which is pretty cool. Like I actually started out as back into the database and whatnot. But it was when I got my first role that they've placed me into front end, I was hired as a Java developer, though, like, I can't even imagine where I'd be. If I was still there. I think I would have quit tack like if I had stayed on the back end. Like it just was not for me. I don't know what about you, Kelly, and Lindsey,
Lindsey [11:18] so I haven't really done too much back. And I actually did a lot more back end during the first year of my career, when I was a junior, but it was mostly with PHP. So I don't know, I feel like I liked it more at the time. But I also did not have any strong front end mentors around me who could advocate for the front end. So it was a bunch of back end developers who hated front end. And I remember, when I moved jobs, I went from the complete opposite situation where it was mostly back end to mostly front end, and then I ended up fitting in that one better, so I haven't really gone back to it since then,
Kelly [11:56] I once took a Python course on Coursera.
Emma [12:02] Sorry, that was the cutest like voice. I once took a course on Python. This is totally embarrassing. And it's like a very slight tangent. But I did write a rap song about Python to Nicki Minaj is Anaconda song, and it is on the internet, if you can find it, you win a prize.
Kelly [12:24] I will shut down this recording right now and go hunt for it.
Emma [12:28] Link in the show notes.
Kelly [12:30] I get final say on what goes on on the site. So if you you know casually see like a link hidden somewhere not actually labeled. It's probably a Emma’s video.
Emma [12:40] If anyone listening to this can find my video from college on me rapping about Python and assembly language, I will give you a special prize, which is probably just a sticker.
Kelly [12:51] pretty special thougt… Okay, so let's talk about full stack development. So this is going to be the most Kelly analogy ever. But picture the front end as spaghetti. And picture the back end as pasta sauce. And then mix them together. And then you have Ali, which is a full stack developer and also a bowl of spaghetti
Emma [13:14] sauce the data I'm confused.
Kelly [13:17] no the pastas the data,
Emma [13:19] what you said the pasta was the front end,
Kelly [13:21] it's the spaghetti. I don't know what I said. I don't know. I'm just thinking my spaghetti. Okay.
Lindsey [13:25] It's two things, essentially that combined together, right? So two skills that go together. And yeah, but because Ali you, you were a full stack developer, you could classify yourself as a full stack. So you have both front end and back end skills. But I actually have thoughts on full stack developer like that title, what are your thoughts on that?
Ali [13:48] So I really like it. Because especially in startups, you can kind of build anything. I like code, I like logic, heavy code, that's what I like doing, I don't care if that's for the front end, I don't care if that's for the back end. That's just what I like writing. And I'm all about the code side of it. And so I guess, like throw me into a project, and I will probably be able to figure it out, at least with some some time. So I like mixing up too. I don't like being in one world for too long. And I've also done so many side projects, that being able to write it all for myself is like a huge asset for me.
Lindsey [14:23] So my biggest thing with being a full stack developer, I think that it's a, it's a good thing to wind up being and knowing how to do both eventually. But something that I personally did when I was first starting to learn to code is trying to learn everything at once and just confusing myself. And I think once I specialized in front end, then I was able to wrap my head around the back end more instead of just learning everything and not feeling like I could do anything. And I think that it might be coming from the self taught perspective versus Ali, you know, you've taught at boot camps before in the past. And I know that they teach you a little bit more of the the full stack. So I think I wonder if there's like a difference in this. Like the way the teaching style is like versus self taught and focusing on one thing before you jump into another or whatnot. What do you think
Ali [15:12] one of my big soap boxes is that being able to understand at least what both are is a huge asset to any developer. So even if you're not writing HTML and CSS everyday understanding what they are, knowing their syntax, and you can spin something off if you need to, is a great asset to you. And you can speak better to have front end developers in the future. Same is true with the back end you trying to build like a basic API or something along those lines is going to give you the language that you can use to then talk to back end developers, and that you can understand the whole process. I think it's also great to teach both because then people can start understanding what they like, I would say that, for the most part, boot camp grads end up in front end, but that's more like 80/20 split than hundred percent. I think that that's also because of hiring standards and stuff like that, too. But yeah, I think that having at least the knowledge, to some extent, the basic basic knowledge of both is a huge asset to developers. But that's just my
Lindsey [16:10] Yeah, I actually love that point. Because talking about being able to communicate with both. So even if you're, you don't want to be a back end developer, a front end developer, knowing how to communicate with them and knowing how to get what they what you need, what you need from them. But like, for example, I communicate a lot with my backend developer and talk about how I would prefer the API to be shaped. And like how I'm structuring the data and how I want my data to be structured. So it it gets output it in a certain way, and I can loop through it with a certain function and whatnot. And so I think that's actually a really good point is even if you're not a full stack developer, you should be able to at least communicate with the other one.
Ali [17:54] Yeah. So I think that for me, especially, so I've had both the title of backend and engineer and like front end engineer. So it's not that necessarily like I'm playing that role all the time. But it's a skill set that I've been able to handle on both regardless, because the end of the day, it's like code, right? So the concept of four loops are the same on the front end and the back end. And so maybe I don't know all the details of absolutely everything. And I've been hopping around a lot. But I think that it's a definitely more of an asset for like early stage startups or something along those lines, where you need somebody that's able to just jump in right code.
Emma [18:33] One other question I want to ask is, what is the difference between developer and engineer because I get so much crap on the internet. If I say engineer, or if I say developer, and it should be the other one, right? So like, my personal take on it is like an engineer maybe has more experience. And architects are thinking through solutions at like 100 level, versus developers may be more code focused, as opposed to like architecture focused? I don't know, do you delineate when you're when you're discussing these things? Like, what are the implications of one versus the other?
Lindsey [19:04] I personally don't care. I know, I know that sounds silly, but I literally just take whatever job or I take whatever the job decides, call me like my current job. I'm a software engineer, I've been called a front end developer too. So I literally just go with what my job title is, and I don't think there is a strong difference between them. I don't know that's, I know that sounds like a silly answer. But
Kelly [19:31] no, I mean, I completely agree. I tend to call myself a developer. I don't call myself an engineer. And it's not really for any particular reason. It's just because I've always called myself a developer. It's what feels right.
Ali [19:42] Yeah, I think for me, I just use developer what I'm saying like front end developer, back end developer, but I have held the title, my whole career of software engineer. And so especially in the United States, where there's no no board that's deciding whether something somebody is an engineer or not, at least in this field, I think that it really comes down to the job. So for some reason, for me, if it's like friend, developer, or back end developer, I use the word developer instead of front engineer, backend engineer, just like the adjective or whatever, almost, and then, but my actual title is always been software engineer.
Kelly [22:48] That's really frustrating.
Kelly [23:47] Before we continue on, we want to give a quick shout out to a couple of our sponsors. Are you a developer looking for your next challenge? Meet Shopify, they're on a mission to make commerce better for everyone. And they do things a bit differently. They don't tell you how to solve problems. They give you the tools, trust and autonomy to build new solutions. They don't want you to work alone, their structures so you can leverage the diverse perspectives across teams and everything you do, and they don't pretend to have all the answers. They're big enough for you to tackle problems at scale, but small enough for you to discover and solve new problems. If you're a builder at heart who wants to solve highly technical problems, and you want to take all of your life experiences and apply them to a blank canvas. Or if you want to access really powerful tools Shopify is the place for you visit shopify.com slash careers today.
Lindsey [24:32] This week's episode of the Ladybug podcast is brought to you by JAMStack conference happening October 16, through the 18th in San Francisco. So let's the jam stack. Chris Coyier got to the heart of it when he said the explosion of new API's and tools are providing front end developers with full stack superpowers. We call this new approach the jam stack here from Chris, Mandy, Michael Katie siloed. Welcome and more at this two day event covering topics from web performance to static site generators to modern build tools and workflows. on day three, you'll have the option to join hands on workshops about service functions, front end adventures, and more podcast listeners can save 10% using the discount code Ladybug, when you sign up. Hurry, the last two jam sack event sold out all the details are at jam, stack Calm, calm.
Ali [25:16] So we're going to transition now into talking about potentially a newer title called DevOps engineer. And here's one of the funny things is that I had the title DevOps engineer for a couple years, but I never did that role, like whatsoever. It's just one of those like misplaced titles, things. So DevOps engineer is essentially somebody who is on top of deployment pipelines, and also making sure that the test environments are automated, and all that kind of process because that's become more and more complex as time has gone on. And so you're trying to make sure that the code actually works before it gets into production. So that's kind of what DevOps engineers are in charge of. They write code, but also do some of the more like sis admin tasks as well. Do you all work with DevOps engineers?
Kelly [26:09] I don't, but my favorite thing, okay, it's terrible. But whenever something happens to like, Twitter or something goes down. And everyone starts saying hug ups is one of my favorite. Yes.
Lindsey [26:23] That's cute. I also, I've worked with a few DevOps folks, one of the people that I worked with a lot in the first few years of my career was really good at DevOps and back, you know, four or five years ago, when vagrant was a big thing that he did a lot of configuration for the vagrant environments, and then like containers, and came about and all of those things and configuring those. And to be honest, like, I know that some of them are a little bit more challenging than others. But the thing that is really cool about that role, is that it gives everybody this a similar environment. So like people who do configure that environment, it makes it super similar for everybody else. So it makes it a lot easier to debug other people's computer issues, I want to say or environment issues, I guess, is a better word, which I find really, really helpful about having that type of engineer on onboard.
Ali [27:24] Yeah, it works on my machine is less of an excuse at that point. Yeah, it's tough work to IU spun up a Kubernetes cluster at some point. And it was brutal. Like it was one of the harder things that I've done. Development wise, that's another one of my favorite words. Yeah, yeah. Kubernetes is their adventure. coolest, I think we can keep that one quick, since it's something we have less experience with. But do you want to talk about QA and engineering? Lindsey?
Lindsey [27:50] Sure. So QA engineering, I feel like does not get enough love. But basically what it is, is quality assurance. So making sure that your code works, making sure you're testing stress cases and stuff like that. And it's for me, I found that my code actually reintroduced bugs when I didn't have a QA engineer. And when I did have a QA engineer, it was quickly fixed, because I was able to realize where my bug came in. And it negated the angry call from the client when you introduced a new bug into your code. And also, the especially with the testing stress cases, that's all also really helpful, even if it is irritating in the process. Because you're like, I have to, I just have to finish this ticket. I want to just have it be done and move it off the off the board. But yeah, I find it really, really hard to have them. And I don't think they get enough love To be honest, they
Emma [28:52] don't get enough low. I when I was at IBM, I had an internship on the testing team. And I, I automated the installation of web spear application server on ZOS. using Python, which is a mouthful I had to memorize. I didn't know what it meant at the time. So yeah, I would say that I was generally working as a QA engineer, intern, and oh, my gosh, that was hard. It's like, there's not enough thanks. And I always made sure to tell our QA or QR quality assurance engineers at LogMeIn that, like they were doing a great job because without them, I would probably have been fired for introducing so many bugs into the software
Kelly [29:28] that goes into just kind of a broader comment there. Tell your team, they're doing a great job, if they're doing a great job, we're really good at pointing out when somebody makes a mistake, or when a team falls short somewhere. Tell them whether when they're doing a good job, you know, everyone can use those compliments, sometimes maybe they're having a really difficult day. And that one comment can turn the day around,
Emma [29:48] and not just tell them but tell their manager because there have been so many times I've gone to people's managers and told them what a pleasure it has been to work with someone. And that can have such a positive impact on their career.
Ali [30:00] Totally, I think this is also a great bridge job to for people who are getting into programming, because it gets you closer to software engineers and people who are writing code, but you're not necessarily writing as much code yourself. So if you're not at that place where you're ready to take on a full programming job, it can be a good, good segue there. I don't know if anybody else has insight on that. But
Lindsey [30:23] no, I think that's actually quite, quite accurate there too, because you get to get a little bit more insight on what the pain points are. Like, you see how problems are fixed. When you find problems and stuff like that. It's a definitely, I would agree with that statement.
Emma [30:37] Awesome. So with that, let's go ahead and shift a little bit into a software architect role if you work for maybe an enterprise company have worked with software architects in the past or day to day. And the general principle is that they they interface with multiple stakeholders in your organization to understand the various levels of requirements, you know, the technologies that you're able to use, how long you know, the development process might be. And some of their responsibilities include determining multiple design alternatives, assessing the alternatives based on certain constraints. So like how much money you have to spend, if there's a specific release schedule, and things like that. I personally have not worked super closely with a software architect, and I don't know enough about it to really delve into it. But it is definitely a viable career path. I would say that there are people who like, I wouldn't think that maybe you you graduate college and go directly into a software architect role. I think it's something that you grow into during your development career. I don't know, do y'all have any opinions or experience with software architects,
Kelly [31:39] I mean, not software architects in particular, but you often see the word architect, its associated with the title, that's, you know, several levels up the food chain, somebody who has been with a company for a very long time, they have a lot of experience they bring to the table. So yeah, definitely don't expect yourself to get a software architect job right out of undergrad,
Emma [31:58] I also think the interface with clients a little bit more, perhaps it kind of depends on the company. I remember when I started at IBM, there was a an architect there. And I he always gave presentations to, you know, upper management to clients, and he was very good at architected his thoughts, done jokes, and he had very deep vertical knowledge of the product, he had been on the team for a long time. And it's something where you have to stick around in a product to gain vertical knowledge on it over a long period of time to be able to crash these decisions, right? So it's not something you can just graduate and jump right into,
Lindsey [32:35] totally at my last job, there were actual roles, like most of the roles that most of the technical roles were technical architects, so essentially the same type of thing where they would be communicating with with the clients, they would be getting the requirements, they would be architected solutions based off of our products that we offered, and stuff like that. So it was definitely really interesting to learn, and see how, like different ways that they approach problems with the same product. So I loved working with technical architects or software architects or however you want to call them. So let's transition here into the developer avocado role or the developer advocate or evangelist roll.
Emma [33:20] unpopular opinion. I hate developer avocado is a term I'm just going to say it I just don't like it maybe cuz avocados, I just don't jive with them. What?
Kelly [33:29] What?
Emma [33:30] Yeah, I avocado and I don't like the texture bothers me every time I see developer avocado, like adjust, I can't handle it. Oh, no, I
Ali [33:39] I think there’s a blog post about it. Mary Thengvall I think? she wrote a blog post about the whole developer avocado thing. And it's kind of cute.
Emma [33:49] Or maybe it's just because everyone's been naming tech things after snacks like snack overflow, and developer avocado. And it like almost makes me hungry. Maybe that's why I resent it. But in any case, let's continue.
Ali [33:59] Cool. So I held this role in half of my job at my at Dev. And so I think that my kind of definition of it is that you're the go between between the developer community and your company. So you're doing a lot of outreach into those communities, understanding their pain points, and what's really working for them, and then coming back to that company and trying to make the product better internally. But this looks so different at different companies. So at some places, it's more of a marketing role, where you're trying to get the product out in front of people, other places, it's more of an internal role where you're working with engineers within the company and finding out their pain points are their strong suits and all that. So what this ends up looking like on a day to day basis is doing a lot of public speaking, building demos with the product so that you're showing off what it does lots of blogging so that you're out there in the community, showing things off and doing that in a written format, a lot of forum and social media interaction to whether that Stack Overflow, or Reddit or Twitter or any of those things. And I kind of like to think about it is just like making friends with a lot of developers and understanding where they come from. And so that was a big part of my role there. So again, looks pretty different everywhere. But overall, you're writing code, but you're doing even more of talking to other developers.
Emma [35:29] I think one thing there was a it was a few months ago kind of blew up twitter at least. But someone had posted about like developer advocates not being super technical, or like they made the assertion that maybe that they weren't on the same level as a software engineer, which again, geek keeping, I hate that. But I just want to clarify here that Developer Advocate have to be very technical, they, you know, they are on the same exact level, technical wise, if not more so than people who code every single day. So if you think that it's all about giving presentations, and not writing code, or not being technical, don't have that misconception because again, like I said, different everywhere, but they should still be seen as equal to engineers or developers.
Ali [36:10] Totally, totally. And a lot of places, it's only like senior engineers that get hired into that position in the first place. But that, again, looks super, super different everywhere. And it doesn't mean you're a less qualified developer advocate, if you have less coding experience, like, I know, very qualified, very great developer advocates who went straight from boot camp into that role, and they're really awesome and shine in that. So you can be kind of any experience level, but I would say towards the more senior end is more common.
Emma [36:38] Absolutely. I think that's a role I think I would like to have at some point. So I would love to learn more from you, Ali. So I think let's transition into a different kind of role, which you might not have heard of, I think this may be a newer role in terms of being actively hired for and that is open source maintainer. I first heard about this role through Gatsby actually, they were hiring a lot of open source maintainer positions. And what exactly do they do so it's a very rigorous job. So the way that Gatsby at least was hiring for it was, I think you would work as an open source maintainer for like a three week period. And then you transition off into doing development for two weeks, because they don't want you to burn out, which I think is super smart. Generally, what you're doing is triage being an open source repository. So you're managing pull requests, you're helping the community members, if they've got issues if they've opened issues. And that requires you to have deep vertical knowledge of the product that you're working on technology. But you also have to have really good communication skills, you have to be able to interface with the community and be able to let people down easily. So if someone opens a pull requests for something, and either it's already been fixed, or maybe it's like not the right fix for something, you have to be able to communicate with those community members. So you have to have really great communication skills. Is this a role that you all have heard of before? Or is this something that you think you might be interested in doing?
Kelly [38:01] I've heard of it before? And I think it sounds super intimidating.
Lindsey [38:04] Yeah, I don't know if I could, I mean, open source is super cool in a lot of ways. But I think for me, it would either be the best job in the world, or the hardest job in the world. For me, I think there's probably a lot of pros to it, like community interaction, along with coding, building something for the greater community, stuff like that. But I think that a lot of open source maintainer is get the mean end of the stick, because a lot of people are like, why is this issue not fixed? Why is this not fixed? Why's my pull request not merge, and you know, you never know what the pain points are for that technology. And a lot of people will only focus on the negatives of what you're not doing, instead of all the positive that you have contributed to. So I think it could be a really challenging job, but also very fulfilling, because there are a lot of people who Thank you. So I think it's just like a mixed bag at that point.
Ali [39:00] Yeah, this was parts of pretty much everybody's job at Dev, because jab is open source. And so a lot of the contributions are from the community instead of just the core team. And so definitely working on that actually, on both sides. Because I was a contributor to the repo before I worked for the company, I think that it is definitely really tough to look at all those issues that are coming in and all the pull requests, and some things are duplicate and whose pull request to you, except if two people do the pull request for the same thing at the same time. And navigating all that is really difficult. But it's also so cool to see the power of open source, and how people are so willing to contribute and to put the work into things and just be awesome community members from a different perspective as well, and to see the different things that get brought up when more people are contributing, right than just the the core team to it. So I think that it's a really, really important thing. And I love that more and more. that's becoming a role within companies. Because it's also kind of a role for individuals to like people with really big open source projects, they get funded to do that, like Henry from Babel and Evan from view. They're both open source containers and do that as kind of a crowdfunded job. So I think that that's really interesting.
Emma [40:16] I kind of forget that. Like, I actually started my own open source project. Like, I don't know why I keep forgetting this, but like, I have experienced this. So it was last September, I, I had this idea for a mentorship app. And I knew I couldn't build it all myself. So I was like, Okay, I'll make it open source. Like, that sounds cool. And then I forgot that that comes with being a maintainer. Right. So like we'd get, I mean, I get emails, every few minutes of people, opening pull requests and merging pull requests. And I think it was a big toll on my mental health for a long time having to triage and, you know, work on those things. And I think once I had to, I had to delegate to right, I had to hire, now hire, it's open source, I had to delegate open source maintainer roles to people to help balance my load, but it is exhausting, right, and especially if you don't know the answer, and have to go do some research on it, too. By the time you're done doing that, you don't want to look at anything else. So I highly respect people who do this professionally, I think. And I think that's what Gatsby does well, is that they transition their containers off of being this maintainer roll into doing coding again, every every few weeks to make sure they don't burn out. But one last role I think we should really touch on here is management. And I think Kelly, you have some experience in this area, if I'm not mistaken,
Kelly [41:30] I have a little bit of experience. Yeah, so let's talk about management. And management can present itself in different ways. So I mean, you can have a product manager, a project manager, but what I'm talking about is a people manager, I'm talking about managing a team of software engineers, the big difference between the and admit like in a management position versus being on like a core development team is that you're managing the people, you're not really managing the code anymore. And you know, you might get your hands dirty on the code and you know, get to work on certain things herself as well. But at this point, your main goal is to help your team succeed. And management is tough, you have to have a lot of difficult conversations with people and you have to make a lot of difficult decisions on, you know, where project is going. And so it's it's not for everybody, but I running my own company means that, you know, if I have a team of people, I have to manage them as well. And I personally find it very fulfilling, and I love being able to watch my team grow as developers and you know, be better and better in their skills. What do you think about management?
Emma [42:37] There are two quick things. Since I've had a few different managers and a couple of different companies. The thing that I've noticed, for managers who were the most successful for me, were that they had to element knowledge. So I could talk to them about technical issues I was running into, and their main priority was me as a person, right? Because I have had managers in the past who also wanted to code and I felt like that came above me, even though that was not their primary job function. And that was, it was kind of a negative experience for me. So yeah, I don't know. And I don't know, we could do a whole episode on on how to communicate better with your manager and the best type of managers and all that. But I don't know, Ali, and Lindsey, what do you think?
Ali [43:22] I think for me, that would be one of my potential career paths in the future, just because I really like teaching and mentoring. And that's kind of what management is, I like people more than I like computers. So for me doing something more people, people centric is kind of, I think, in my future. So I think that it's great. I think that a great manager really makes the job. And the great managers that I've had have pushed me so much forward in my career and have made things so great for me. I'm so thankful for them. But also bad managers have led to a super toxic work environment and really, really hard and hurtful there. So the importance of management, I can definitely see and so I must be such a challenging job. And so,
Lindsey [44:08] yeah, totally, I think, for me, I agree with you on that with how it can make or break your job. From the career aspect. I don't see myself going into that that soon. Because I'm I feel like I'm not ready to quit cut will not quit coding, but step away from coding, because I think one of the most challenging things about being a manager when you love coding is that you have to delegate a lot more. And I'm not ready to do that. I'm not ready to give up my give up coding things. But I will say the thing that's really cool about being a manager is you are judged way more on how your team performs and how well you develop your team and less on how well your code runs or how performant your code is. And that's a challenge that some people would love and be really well suited for. And others not so much. One of my favorite bosses ever pretty much said that to me. And she actually has a great talk about transitioning from being a developer to being a manager. And I should link that in the show notes. Because it was incredible. And really lots of good advice for people who want to go through that career transition. So
Kelly [45:19] and that is one of the most difficult transitions you can make. Especially if you're within your same company. If you're go from being on the team, to managing that team. That is a very difficult transition because the people who were your coworkers are now your direct reports, you are responsible for their success. I cannot recommend enough. Read books on management. If you decide to become a manager, if you are asked to become a manager, if you're promoted to be a manager, there are so many really great books on management that I'm going to include in the show notes that, you know, I don't have that much experience being a manager and my husband became a manager around the same time I started hiring a team of people. And he's been really big on reading all these books. And it'd be it's been wonderful having the those as like resources just to jump back to if I encounter a very specific situation, it is in one of these books, and it tells me exactly how to handle this situation. So all of those resources will definitely be in the show notes.
Emma [46:17] And not just management books to like, I highly recommend cultural communication books, the culture map is I will not stop talking about it. And so I'm no longer on this earth because it is one of the best books I've ever read. And it talks about how to communicate effectively with different cultures because we have different ways to communicate. So yeah, I highly recommend management and cultural books for sure. And just to segue a little bit, you know, we touched on a lot of job roles here, we went into depth on some of them more than others. But there are so many more options out there, if few others that we didn't touch on were security, cyber security system admin, even company founder, which Kelly also has experienced with and if you want to hear more about that you can go listen to our Ask Kelly, anything about entrepreneurship episode, but really, you know, the sky's the limit. There are so many options out there. So with that, I think it's time for our wins. So our community win this week is from Katie Bowers. She said after being let go from a highly toxic workplace, she started her own freelance business and is close to landing her first client. So congratulations on that, Katie, and I really, please let us know if you did land your first client. We would love to hear from you. Lindsey, what about you? What was your win this week?
Lindsey [47:32] Yeah. So in one of the past episodes, I talked about how I was procrastinating on making egghead videos. And I've actually created two in the past week, which is really cool. So yeah, I finally got a lesson out and I'm starting to batch record some of those and hopefully get started on my course. So about what about you?
Emma [47:52] By the time this airs, I will have been or be on my honeymoon. We're going to Spain for two weeks, which is super fun. So that is a huge one for me. Ali, what about you?
Ali [48:02] I think mine's along the same lines. I am going camping with my dog Blair for a couple days this week. And I'm really excited about that. Lindsey, how about you, Kelly?
Kelly [48:10] Um, I had my first pull request for an open source project approved, which is really exciting for me, because I work on a lot of you know, because of what I do for a living, I'm working a lot of client projects. So they are all private, I can't really spend much time contributing to a lot of open source projects. So I found an opportunity to add some graph QL API endpoints to Gatsby for their Shopify connection with the storefront API. And it was really exciting. I was I was happy that I managed to do that. It's kind of intimidating, like submitting your first pull request for an open source project.
Lindsey [48:49] Oh, yeah, totally. I think I did my first one, maybe six months ago. So not considering I've been doing it for a while. I was always intimidated to do that. So
Ali [49:00] I think even still making like your hundredth pull request is so intimidating. It's like, Did I miss some sort of rule? Are people going to judge my code like all that I still freak out. And I've done so much open source contributions, but
Emma [49:12] I always joke that I had never worked in open source and I started my own open source project. And the I remember the first time like opening a pull request to my own project, I had like the biggest, you know, hit of imposter syndrome. I don't know if it gets any easier
Kelly [49:24] I’m gonna judge myself.
Emma [49:27] I'm going to reject my own pull request.
Lindsey [49:29] Awesome. Before we conclude today, we want to give one last shout out to our sponsors, Saturday, Shopify and jam stack. com sponsors allow us to continue giving you the show for free while showcasing some incredible technologies and opportunities. Thank you again to our sponsors. So with that being said, if you liked this episode, tweet about it will select one tweeter to win Ladybug stickers each week. We post new podcasts every Monday so make sure you subscribe to get notified and leave a review. So have a great day. Thanks