Stop Letting Feature Requests Kill Your Codebase!

Transcript is auto-generated and may contain errors.

Hey folks, I'm just driving to CrossFit. We're going to Experience Dev subreddit to talk about Technet. And uh specifically, this person was asking for some some help, some perspective on asking their manager to prioritize tech. Um they said in their post that like this used to be something that was getting prioritized I guess it seemed but uh now more recently it seems like their manager is pushing back a lot because they need to deliver features more. This kind of sounds like the the typical age-old battle between you know do ship more things versus you know uh make code prettier kind of thing. like that's probably what it feels like. So, figured this would be a good one to talk through because it's I don't know like a very common thing that comes up like all the time. Every team, every company, doesn't matter. Like if you haven't experienced this yet, it's probably just because it's about to happen.

But uh yeah, I think this is a really common one and it's tricky because it's a prioritization challenge. Uh prioritization, communication, all sorts of things. And I think especially if you are more junior and either this hasn't happened yet or it's kind of happening for the first time and you're confused and it's like frustrating. Um it's I think good to think through and and understand maybe what's going on. So I often like I think the more common way this happens is like you get a few things stacking up and that's going to be that whoever is in sort of in charge of of prioritization, right? Like so product owner, engineering manager, however things are set up, a combination of all the above. the further that people are removed from code, the more um or I guess like the less understanding that they'll have directly of how areas of the code impact uh you know the ability to navigate changes there, right?

And that could be for a couple reasons. That could be for adding new features. That could be for fixing bugs in those areas. But, you know, when you when you have people that are further and further removed from code, the harder it is for them to just like understand these things inherently. And I don't mean conceptually, I mean like specifically from an area of code. And I guess arguably conceptually that starts to fade too, but uh but I I mostly mean like specifically related to areas of code in your codebase. Um they're they're not going to know these things. uh of course as obviously as you if they're not spending time there and I'll go on to say like even in my role now so for those of you that are kind of sort of new here uh I'm an engineering manager at Microsoft I've

been at Microsoft for just under six years now I've been programming for over 20 years but I don't actively program in my I don't write code in my role right I write lots of code outside of work I love to to program and build things. But in my role at work, I do not write code. Uh not that I'm not allowed to or anything, it's just there's enough other things that I am responsible for that it doesn't make sense for me to spend time writing code. So there are absolutely many situations where like I am just not aware of like where there is tech debt and I must rely and trust on my team to be able to talk to me about it, bring it up and then um kind of what we'll get into is like I have expectations on them that when they bring that up they need to be able to articulate to me like why that's important.

So I think you have this one factor of like being removed from code uh for people that are are making decisions around priorities, right? Like that's a huge factor. Then I think when you couple that with the fact that uh businesses in general, right, there's always seemingly more and more and more pressure to get more things done. And so again for context before Microsoft I was at a startup at a startup it was constantly you know how do how do we just get more things done there's like a truly an infinite amount of work that has to get done a lot of the time you know kind of seems like what's a good way to say this um it's there are so many like uh I I want to use the word bets because it feels like sometimes that's what it is. It's a you know there's uncertainty but like we think we have to do it.

So I would call it more like a strategic bet. So it seems like there are many strategic bets that we want to go try as a startup. And so there's it feels like you're being pulled in a million directions to go do things and do them faster. But also like you know I have different but uh relatable experiences at a big tech company like Microsoft where maybe it's less about uncertainty around strategic bets but it might be more like it's a huge company and even just the area that I'm working in there are many teams and so there are many teams with different strategic bets that they're doing. It feels like there's a lot more certainty, but there's a lot more surface area to go do. So, there's this constant pressure of like more has to get done. Now, when you layer in over the past like for those of you that are paying attention to like job market and stuff like that, there's been, you know, challenges with hiring, being able to grow teams.

So, you have that kind of factor. Uh, by the way, this isn't like a a Microsoft specific thing. Sorry. I just mean in general with companies and hiring. So you have hiring slowing down andor stop andor shrinking work forces in some places. So you have that going on. You have this factor of like this is a huge one for many companies, right? Like we're going agentic. So like you must you as in the people that are building the things you must find a way to to get that 10x productivity even though there's fewer of you in in many cases right like cuz the the teams are shrinking. So there is this factor of like do more, do more, do more. And it's getting like overwhelming, right? It's always been a challenge. There's always been this kind of feeling of like how do we how do we do more with uh not more people?

How do we do more with fewer people? Uh now do more with fewer people. And we have this pressure of like well we we made a strategic pivot to use AI. So, like you better figure it out. I hear this a lot from different uh places where it's like, you know, it's a strategic AI move. So, where where is that productivity? Like, we're relying on you to show it. So, I think in my opinion, these there's more. I'm sure there's always more, but there's these two really big factors that come into play for conversations like this. From a who is doing the prioritization perspective, these two things influence a lot. Pressure to constantly deliver more uh and often with less plus detachment from specific areas of the code. Okay. So with that said, you as someone who is working actively in the code and you are getting that that pressure kind of downstream as well.

So if your manager is were um you know these other roles are getting pressure to deliver more and more and more that's an expectation of the business. You know, I would I would say that uh you know, from the perspective of an engineering manager, there is a lot of responsibility there to not make it feel like a a crippling amount of pressure to the rest of the engineering team. Like the engineering manager should be absorbing a lot of that and providing some like shelter to the team. I'm not saying that they make it such that the team doesn't know that there is a you know some some amount of pressure coming through so that they understand what's going on. But I mean I wouldn't I wouldn't want an engineering manager to amplify that because I think that that's not productive and I think that it's not helpful.

So team is ultimately going to be getting some of this pressure downstream right in some cases unfortunately even more which I don't think is fair but what the team is also feeling is like hey look like we're working in these parts of the code and a lot of the time to move fast to meet these deadlines a lot of the time we don't have sufficient amount of I don't know like runway to be able to So to build the thing the proper way, right? And it it kind of it can creep up over time where I'm just going to make up an example. You know, you want to go build out feature A and deliver it in, you know, your a one week or twoe window, whatever. And you're like, okay, well, the sort of northstar, the direction we want to go with this is that we'd have to do, you know, X, then Y, then Z.

And if we wanted to do all of that, it's probably going to take us like I don't know, like as you're working through it, it might be a month, it might be two months, and you're like, "Okay, but if we get part A, sorry, I'm mixing up letters. Uh, if if we get part X done here, uh, maybe we get partway into doing Y, maybe we can get it finished, but like certainly we're not going to have time to get Z done uh to ship this. But we can come back to that, right?" Like we know that's the direction we want to go. Cool. So, let's definitely get X done. We'll try to get Y done. And even if Y is not fully done, we can probably ship this with a bit of a tweak and that way we can get feature A out on time.

Like, we'll make it happen. And so, you do this work and ultimately, you know, uh you either get part X done or you get part of part Y done, but you don't get part Z done for sure. And so as a result, you're kind of like you're partway implemented for what you were designing for. And so now there's a bit of tech that you're kind of in this intermediate state, but it's like it's good enough for this feature. And you could always come back and get the rest of it done, right? We'll do it the next sprint. But inevitably, what happens? Well, what's more important? You've already shipped this feature. It's already working. What's more important? the next new set of value to go to customers or to go fix up this tech debt, right? Odds are if it's already shipped and already working, like odds are it's not a higher value to go code up whatever the follow-up work is.

I mean, this is a contrived example, right? I mean, maybe it could be, but what what what what do you need to get done on that? Like on part Z that we were just kind of making it, what needs to get done there that's actually going to be more value than net new net new uh shipped features or bug fixes for for customers, right? it it becomes a a really difficult cell because if it was truly needed, it would have blocked the feature from going out, wouldn't it? So now, if you want to get that work done, you need to make a business case for it because it's literally directly competing with needs of the business. And this is challenging, right? Because like it's frustrating because it keeps happening. Hey, I just made up an example with one feature. Odds are you're not just shipping one feature.

That's not what your team's responsible for. Odds are you're multiplying this out by two, three, four, five, or six things. And this just keeps happening. So over time, you just keep bleeding in more debt. And I'm a believer that basically every line of code we write is tech debt to some degree. But in this case, I'm being more uh specific about there's just these like literal gaps that we realize that we're introducing because we're aware that we're kind of taking these shortcuts to get things done. And sometimes when I use the word shortcut here, I don't mean that in like a super negative way, like we're obviously hacking together. I just mean that like it's not it's not exactly what we designed for and we're leaving like opportunity to make things technically better on the table.

In some cases it very well might be like man we really had to hack this in and like that is what it is but in some cases it's not a deliberate like oh my god I can't believe I wrote that line of code. It's more just like, okay, we didn't get the full thing done, but the the feature works, right, and we can ship it. Whatever is left is not really visible to a customer, let's say. So, this challenging situation where like you're kind of bleeding in more and more debt and really what you want to be doing, especially from the perspective of folks that are working in the code all the time, is like how do you shrink that debt more and more and more? And uh it just comes back to like being able to make a point for like how do how do you pit that against shipping other value?

Because unfortunately those conversations often look like you know as a software engineer I think that we should focus on this work here's the reasons why and all of those reasons are very specifically around like you as a programmer or the codebase and I need you to like think about this from the perspective of who is doing the prioritization okay we've already talked about one acknowledgement that Like a lot of the times is people that are further and further removed from code. And if one of the biggest arguments that you want to make to them is like something specifically about code, number one, it's going to be challenging to kind of align that in a way that they're really going to understand effectively. And I don't mean that to say like, oh, they're stupid and they won't get it. I mean like what they're thinking about and focused on is not specific classes and lines of code and different methods you have.

It's just not sort of their focus even if they get it technically right. So you have that but then also the things that they are more focused on are literally or should be things that are shipping value to customers. So, a lot of the framing that people have for for tech debt and why we should prioritize it is like from the very beginning, not framed in a way that's going to be um sort of helpful or get buy in from the people that are prioritizing. Right? I think we need to go spend a full week rewriting this part of the code. All right? We're going to refactor this class uh or these classes so that the system around it like just is a we're able to work more effectively in there. Um the code's a mess and we hate touching it. Okay.

So, like why why should I prioritize that versus like fixing these three critical bugs that customers reported and these two other features that if we were to ship them, the sales team can go uh actively, you know, chase down, you know, five more customers? Why should we go clean up this code? And and so my point here is not to say that there's never a time for techa. My point is to say that if you're it's almost like you're automatically going to lose if you can't come up with something comparable and that that's like a really kind of like shitty I don't know like shitty experience is like now now you have to go pit your tech debt against like you know value being shipped to customers. But I think there's a way to do this and that is to explain as much as possible, right?

If you want us to continue at this pace and we're constantly doing these things, these areas of code need to be addressed because we're noticing that, you know, as we're spending more and more time here and it's like this area of code is actively being touched. It's not some legacy on the shelf thing that we haven't touched in 4 years and we will continue to not touch for 4 years. It's like we're actively in here and you've noticed that we have to go keep fixing the bugs. You have two of the bugs in this sprint are like literally related to code in here and we keep breaking it. We cannot keep working in here because we keep breaking it. We can't test it effectively. It's convoluted. People don't understand it. We need to slow down a little bit here. clean this up so that going forward we have less of these bugs coming in.

It means that we'll actually be able to deliver these two other features you're talking about more effectively going forward, right? It's going to take us a week to slow down, but going forward those features we could do in half the time and you know you have more of these coming up in the same area or we know they're in the same area uh based on the requirements that you've been kind of hinting at. So like my point here is that the more that you can start to shift how it will uh speed you up on related work, how it will reduce uh bugs that are are clearly causing an impact in terms of velocity and productivity. Finding ways to articulate this stuff that's not just this code is a mess. It's this is going to help us do other things more effectively or spend less time on wasteful things.

I think is a huge huge huge opportunity to kind of uh to pitch these things. Um I'm at CrossFit, so I got to wrap it up there, I guess. But uh one final thing I wanted to mention is that I I do think unfortunately like as someone who has to like my entire job is prioritizing things um at the end of the day I think you you have to accept that there's going to be situations where things don't get done and it's it's a really difficult thing to kind of like accept but uh Like there is an infinite amount of work that has to get done. I have I have things that are even business value I need to ship for the teams that I manage. Forget tech debt. Forget, you know, things that feel like bug fixes. There is so much to do always and it's quite literally impossible to do all of it and it's an endless stream of things to prioritize.

And so I I just want you to know that at the end of the day, there's only so many people and so much time and we have to keep trying to put things in a priority order and work through them. And that might mean that some stuff that we've talked about and planned previously and we're like, "Oh, we'll get to it." It very well may never get done ever. And that might be actually totally fine in the end. Right. So, finding ways where you can find those opportunities to bring things up, uh, organize them from the perspective of like the person that is trying to prioritize, what's going to make that clear to them why it's a value. That means that you have to think about it in ways that's not necessarily a value to you, but a value to them. I hope that helps. I realize it's a challenging kind of thing to navigate, but I think reframing your perspective uh can can help make that easier to navigate.

See you in the next one. Take care.