Most of My Job as a Developer is... Maintaining Existing Code?!

Transcript is auto-generated and may contain errors.

Hey folks, we are going to a submitted question. This one says, "I feel more like a maintainer than a developer or engineer. I often find myself having to look through existing code that somebody else engineered to add on to it or add features. Sometimes this just isn't challenging enough for me. It makes me feel replaceable. Is this normal as an entry-level developer? What can I do to overcome this stretch of my career?" Awesome question. So, just a friendly reminder for folks, if you want questions answered, leave them below in the comments or go to codeccommute.com. You can submit anonymously like this person did. Um, let's dive into it. So, I got a spoiler alert or a news flash, I guess. This is probably um what most of us will be doing for most of our careers. And I say that because if you're working at a company that has income, right?

So they have money coming in to be able to pay software engineers. It's because there's an existing product or service that's doing that. And so most of our time is actually spent adding to maintaining building on these products and services that already exist. Okay? So it's not that and let me kind of put some terminology out there. There's like they call it like it sounds kind of weird like brownfield projects but like green field projects are new things that you're going to be working on. So, hey, we want to go spin up a new website or new mobile app or new something else, right? And that is something that does come up, but it's like you're not doing that every week. It's not every week like let's go make a new thing. Let's go start from scratch. This is something that you do a lot of when you are doing side projects and things like that because you don't have to ship them, right?

You can stop whenever you want. You're just learning. you're playing around with something, it gets to some point, you can say, "Cool." Like, "That was fun. Let's go on to the next thing." But when you start having paying customers, and those customers that are paying you for the product and service that you're offering are the ones that enable you to have a business to be able to pay employees, you have to keep building on these things. So I would say and there's obviously different people watching this with different experiences. Um what I'm talking about is what I would say is the typical sort of I work for a software development company and we have a product or service that we're offering. This would be probably similar if you're working at a company where software is not the primary thing that's being done at the company, but you work in the software part of that.

Um, so just to give you an example, like I I work at Microsoft right now in a spot that we build software. And so software is everything we do. We're building software to support the software to support people building software. It's all software. Um, there are other parts of Microsoft that are not just software. You might work at a different type of company where they're building, I don't know, or offering a service. I'm trying to think of something. They're offering insurance. Okay? Like insurance is the thing that the company does, but they have a software part of their business. Maybe they're building their own um their own sort of platform for offering insurance or managing customers, stuff like that. And you work in the software department for that. So there's there's so many different flavors of this. But the other thing to consider is like if you're the kind of person who wants to be constantly doing new things.

Maybe there's a different path. Maybe that is more like doing contract work. Maybe that is doing more freelancing where you can be I don't know what this person actually does for work in terms of like the domain, but that might be something where you can be starting fresh more regularly. That's more interesting for you. it's more um something that's going to keep you engaged because I want to I want to acknowledge here this is a sort of like a philosophy or a theme when I talk about careers and stuff. I want to I want people to find things that they love to do, right? Not just, you know, should should pay the bills. Um but I don't want that to be the only thing like for a long-term path in people's careers. I think you should enjoy it. So if that's going to be a deal breakaker in terms of your enjoyment engagement, I think maybe there's different areas to kind of move into.

But yeah, my perspective on this is that in a sort of typical software development company where that's what you're doing is building products and services is most of what you're going to be doing is this. Now, this is this is actually like a huge huge huge topic because I've worked in um in prototyping teams before Microsoft like most of my career I was rapidly prototyping stuff. So I had six internships and aside from I mean even the one that was doing contract work like given how like agile it was and I mean that in like a in a very true sense. Um a lot of prototyping uh and kind of back and forth with the customer. But my internship like I had a an architecture internship where I worked on the architecture team and all we did was prototype. When I worked in a digital forensics company, I did a lot of prototypes that would turn into products.

So, it's not that these types of things don't exist. I just think that it's not the the most typical sort of situation. Um, so we could keep going down different directions on this, but I want to kind of touch on some other aspect of this, which is uh some of the phrasing in here, right? So, I often find myself having to look through existing code, right? somebody else engineered to add on top of it. Sometimes this just isn't challenging enough. So something that I think is interesting about this is like when I think about software engineering, I think about um operating within constraints. Okay, so when we're talking about building things from scratch, you have very few constraints in comparison. If you think about let's think of an example like you have um a system let's do like a customer management system and so okay like what what platform are we going to like what language and tech stack we're going to use okay we're going to pick C and ASP.NET What database?

I don't know. I like a SQL based database. Postgress, MySQL. Either of those is fine. Okay. What are we going to like where are we going to host it? I don't know. Like I used Azure and AWS. More recently, more Azure, Microsoft bias. Yeah, let's go Azure. See like how I'm kind of going through this is like there's lots of options in terms of tech stack in terms of things we can do because that's the reality there are lots of options there's you know a billion ways that you can go build a CMS even when you have requirements and like for features and functionality that you want to add in terms of the tech you pick you can go so many directions so what happens when you are working on a CMS and someone's already picked the tech stack. It's not SQL. They picked MongoDB. Okay.

So, that's one part carved out. And it wasn't in C. And that's the thing that I like to use. It's actually I don't know, it's in NodeJS for the back end. And there's a a nice React TypeScript front end. Okay. Now, we got to work within those constraints. And it's a live service. that's running with many many customers. We have um I don't know 10,000 monthly active users and now you want to go at a feature where you have to touch the database. Okay, if this was a green field project and we had no users, just go change the database, man. Who cares, right? There's no one paying for this. But when you have a lot of users, it's no longer just like, hey, go go go alter the table. Like, how are you going to migrate that data? Do you need to migrate that data?

Can you schedule migrations? Uh how do you even deploy the features out? Do you have to roll this out over some period of time? Like you have so many other interesting constraints. And I think that my eggs are ready. So um something to think about in terms of navigating constraints in terms of engineering, not just is it new and shiny. So something to think about.