WTF! This Developer Rewrites Everything That They Touch!

Transcript is auto-generated and may contain errors.

Hey folks, I'm just leaving the office. It's going to be a long drive apparently. Um, it's life, I guess. We're going to experience devs on Reddit. Topic is get out of here, Google Maps. Uh, topic is dealing with rewrites. And, um, there's a a bit of a story here. I'm not going to read the whole thing because I want to drive. Um, basically the context of this one is that this person is a tech lead of a team of five devs. Um, and it seems like there is a dev that's more junior to them. So, they have three years of experience mostly in the uh the front end. Now, they're they have been seeing that the way that this front-end dev approaches things in general is uh they go to work on something and they don't they're they're basically rewriting anything they touch. So, you can kind of I don't know interpret that how you'd like.

Um, so if it's a function, if it's a class, if it's a whatever part of the app that they just go rewrite it instead of like modifying or touching it, it's rewriting chunks of the app. And um, apparently to this person, you know, wasn't an issue because the front end team had less people. So like whatever, just go kind of get your done. And uh now that this person's doing more um more in the back end, it seems like um they're continuing the same pattern. And this is where the tech leads kind of like, okay, we got to got to do something about this. I think because they have uh you know I'm not reading it all verbatim but it sounds like they're having some challenges where um like that's all this person is doing is rewriting everything they're touching. So the tech lead is trying to be like look man like that's not how this works.

Like you don't just keep rewriting everything. Like you have to be able to like have a middle ground. Um, and it seems like the push back has been like, well, no, like from the person with less experience, like no, like that's how you end up having bad code. So, I just keep rewriting it so that it's not bad essentially. Um, but then what happens is like uh big surprise, maybe not. Um, there's there's regressions like all of the time because this person's just rewriting code that they don't actually understand. So, the senior dev's been um the tech leads have been kind of like starting to reject this stuff and you know try to make more of a point about this, but now they're butting heads on this kind of thing and uh I thought it would be an interesting one to talk through um because we can talk about rewrites and refactors as well.

So, a couple different angles to take here. Before I dive into that, friendly reminder that if you want questions answered, leave them below in the comments uh related to software engineering and careers. I'm happy to try and answer. Otherwise, send them into dev leader on social media. It's also my main YouTube channel. Go check that out. Um, and yeah, if uh if you think that this is a helpful response, you think it's interesting, if you want to do me a favor and share it back to experience devs subreddit, that would be super cool. Otherwise, sharing it literally anywhere is super helpful for me. Uh, I make almost enough money from this channel to pay to drive in the fast lane. Almost. So, we're we're not there yet, but hey, that's that's not so bad. Almost covering the fast lane. So, I appreciate it. Thank you so much.

And um with that said, let's dive into things. So, first of all, I want to talk about um kind of the behavior aspect because that's I ultimately probably why this person's writing in is not to debate rewrites and versus refactors, but mostly about like how do you like navigate this kind of thing. So, we'll go through that and then I want to spend some time talking about um why I personally when people talk about like boy scouting changes like you know refactor as you go um I've had terrible experiences with this not all of them but enough terrible experiences where like I don't actually encourage that people do this at the same rate um that a lot of people talk about it. Oh man, you got to figure out how to merge lanes here. you're going to cause an accident. Today's a really good 360 camera day and I'm not running it.

This morning was embarrassing for a lot of drivers and uh seems like the drive home is uh comparable. So, yeah, I' I've seen enough people that are trying to, you know, just do a little bit of cleanup and um no, they're literally just rewriting everything as they're going. Um and it's just chaos. So, um, let's talk about this, right? So, behavior-wise, we got people butting heads. We got someone who is the tech lead who is, uh, you know, not supposed to be an right? But they should be able to make sure that they are guiding what's happening in terms of, uh, some of the, you know, coding standards, best practices, things like that. That's why they're in this position. team lead, tech lead, slightly different in terms of title, but everyone has their own interpretation. So, if it's a tech lead, right, they should be having some type of uh input on this stuff.

So if um if they're butting heads on this kind of thing, right, they like ultimately what should be happening is that the tech lead has has they've been given like sort of the authority, right, to be able to say like this is how the development process is supposed to be looking on the team. That doesn't mean they can't be challenged. It doesn't mean that the team shouldn't be talking about best ways to do things, but based on how this is written in this Reddit post, it certainly seems like, you know, uh, this this person's the outlier that's going around and rewriting things and and now butting heads with the tech lead. Do we know that for sure? No. But like, let's go with it, right? Because otherwise, it's going to be a pretty messy thing to try and navigate. Um, I got to switch lanes here behind this stupid bus.

Don't want to be behind a bus, man. Um, okay. So, this tech lead needs to be able to navigate this with this individual. Um, and I just want to say that ultimately if they are trying and it's not working, then it needs to be a conversation with the manager. Um, but how do you kind of get the ammunition for that? Like, right, what's the evidence? Like, what's the thing that you want to be able to focus on? And as a software engineering manager, I'm trying to put myself in the situation of a tech lead coming to me and saying, "Hey, look, we got a problem and like I want to talk through this because I've been trying." The first thing, and I talked about this on the video that I recorded this morning, is that I always encourage people on my teams to try and sort things out um together first, right?

Nothing wrong with escalating it to me. If you need help, always like I want to be there to help. Um and that's great. But my my first sort of action is generally, hey, like have you tried talking about this with the person? Right. I I like leaning into that because I think that when you have friction, um especially between colleagues and stuff, honestly, taking the opportunity to have that that awkward conversation, that difficult conversation, it sucks, right? But I've shared this before that I don't have stats on it, but anecdotally I can say that it almost always ends in a better working relationship. Okay? So, I do recommend that people do that. I know it's easier said than done, but that's what I'm going with.

Um, if people needed to escalate it, so let's say this person came to me and they said, "Nick, I'm the tech lead here and I'm having this issue with this employee and here's what's going on." like what are the things that I would want to be able to understand so that I could go try and drive some progress here. I think first of all is like um I I'd want to understand what kind of communication's been happening, right? So I'd want to know what are these situations? Is this a one-off thing? Like is it happening on repeat? Uh what's the impact of this? Right? So, in this case, this person's been saying, "Look, like this person's rewriting stuff and like it's literally having negative impact. It's not just like a it's not just my opinion now, and I'm I'm butt hurt because they're rewriting stuff.

Uh, which by the way, I I just don't think is a super efficient thing to do in the first place, but it's literally causing detriment to the team because it's causing bugs, right? Uh, for context, by the way, like if for folks that are newer, um, if if you're not I don't know if you're not like super familiar with like code rewrites and stuff like that, I'm just going to explain this like very briefly. Um, when you have code that's written, it has a set of behaviors, right? Like obviously it's been written, it's going to do something that it's been coded to do. Um, you can go write tests on that, right? And then you can try to have regression coverage so that if someone touches the code, it doesn't break the expected behavior. All good and well.

The reality is like you can and will very likely will run into scenarios where even if you have tests on some code, people can go rewrite things and there isn't test coverage or whatever it happens to be. Like there's tests but they're not great tests. so many different variables here, but the reality is that regressions get introduced and it's because you're changing stuff, right? When you have Sorry, I'm there's like a a lot of cars trying to change lanes and stuff, so I'm pretty distracted and I don't want to get all hyped up about people breaking Um, got a couple more lanes. I got two more lanes. Um but yeah, if you're like if you're not uh if you don't have experience like going over and like trying to rewrite something or heavily refactor it, um like refactoring by definition is not supposed to change the behavior.

But like um you'll see when I get ranting about this a little bit later, um the lines between people saying I'm just rewriting or I'm just refactoring this versus a rewrite, they get blurred a lot. Um, and when people talk about this online, they love getting pedantic about it. They love saying like, "No, well that's that's a rewrite then. That's not a refactor." So everything I was saying about refactoring holds. And I go, "Look, man, I get it. But in practice, like, good luck. Good luck having this conversation because then no one's ever refactoring anything. Everyone's always rewriting stuff because in practice there's a lot more people rewriting stuff because they've changed the behavior." Um, anyway, it's just like people, like I said, being very pedantic about the definitions of things, which I don't disagree with the definitions, by the way.

I'm just saying in practice, like if you want to die on the hill of saying this is the definition of it, therefore your argument doesn't apply, I'm like, I don't know, like go code in the real world. Um, okay. So, as the manager, I would want to know about like conversations that have been happening, how regular it is, um the impact that it's having. Like, these are things that I'm looking for because when I go to have a conversation with this person, what's not a useful conversation is be like, "Hey, Billy, tech lead really doesn't like working with you and and like and uh seems like you're just causing problems and you shouldn't be doing that." Right? I don't want it to be like a tattle fest. I don't want it to be just me relaying like what probably what this person's been told. What I want to be able to do is talk about not um like I want to remove the the personal part, right?

Like I want data, right? I want to be able to explain like this is the impact that's being had and then we can start talking about forward direction. I also want to be able to hear from this person like their side of things. I talked about this in the video that I recorded this morning, which I I can't even remember the topic. It was also from Reddit. Anyway, um I when we whenever we have situations like this, like a Reddit post where someone's talking about things, we're only getting one side of it. So, I would love to hear what this other person's side is. Even if the person who wrote this post is spoton and that's like the reality of the whole situation, great. I'm not saying they're a liar. I'm just saying like it's it's my responsibility to make sure that I'm hearing multiple sides to this.

So I'd want to understand um ultimately I would be trying to back unless there's something I don't know from this situation. to be trying to back the tech lead and saying like look tech lead is supposed to be the person who's going to be uh trying to have direction over how this code is how this code base is shaping up or the processes that we have around this. So like I would want to defer to their expertise on it. Now, if I felt that there was a gap here, which is also why I want to hear from this individual, then I would love to be able to go back to the tech lead, maybe get this person and the tech lead together and have a sit down conversation and not pit them against each other, but say, "Hey, look, like we're going to talk about

how to make this process better, right?" Um, off the top of my head, I'm not like I would I would need a little bit of time to to sit down and think about how do you make a conversation like this not seem like you're pitting people against each other. Um, but I would, you know, I need to sit down and kind of think about that. I am sitting down. I'm just not thinking about it. So, my strategy, like I said, would be trying to get data from both sides, trying to share the impact because then it's objective. It's data driven. and then kind of uh you know uh reinforce like the the role expectation. From there we'd see if there's something that we need to do to actually improve the process though. Um why Sorry, work messages. I have ah it's like two two things at once that I like cannot stand.

Um, you probably heard of like no hello, maybe not. Um, when people send messages that don't have the actual context of what they want, I can't stand it. Drives me nuts. Uh, like instantly I get instantly aggravated. probably like um I probably have more of like a a negative response to that than I should, but like it drives me nuts. It almost And I know this isn't the intention of it, of course. It almost feels like it's insulting me. Like I it really bothers me. Um which is weird. I know. So, a combination of that and then like and then immediately like not in in the time that I saw the notification, which would be zero zero time to actually respond to it. In the time that I saw the notification, they already were engaging on a different path. And it's like I I don't even know what I would be expected to do right now.

So, combination of things that I just really don't like. Um, but that's okay. I'll sort that out when I get home because work doesn't end, right? Um, anyway, in terms of this tech lead that they needed, I it sounds like they've been trying to work on this with this person. They're kind of hitting a wall. So, I think they're at the point where I would recommend that they are uh engaging the manager. The part that I was going to mention is like also like uh you can structure this around like performance and expectations, right? The um the reality is if this person's butdding heads and they're causing friction and and that's causing like more harm than good. If this person is unable to sort of collaborate with people on the team, the tech lead has a responsibility here too. Of course, right? This is again you need both sides to it.

But if we if if we're assuming that the things that the tech lead is saying are accurate and this person's causing a lot of friction, they're sort of the outlier that's causing friction, like other people on the team aren't also just rewriting everything, right? Um this is the kind of thing that you could transform into like a performance conversation where it's like hey look like um you know the yes you might be having uh you know good progress in being able to uh deliver features and things like that like that's good but also the quality of your work is not there and by what metric? all you're introducing bugs like left, right, and center, right? Like it's not a matter of like literally having like a a counter beside you and uh or like going through I don't know like crawling the code base and trying to drive metrics like this.

But it's more like if there's truly if there's significant enough incidents and recurrences where um you have people that are introducing changes, breaking stuff like that can be a conversation that's like the quality of the work that you're doing is not up to par and we need to have a conversation about it. So that's one thing on the collaboration front. That could be another thing that's like a coaching opportunity. Um communication, right? So if someone's trying to say, you know, this person's argument is like I need to rewrite the code um because you know their argument is like it needs to be better. It needs to be more readable. I don't know what the argument actually is. If they're not able to articulate that properly, then like that's another coaching opportunity. I'm not here to say that code should never be rewritten. But if every time you're touching code, you need to go rewrite all the code.

Either somehow all of the code in the code base is the worst and needs to be rewritten all the time, which I find hard to believe. I think that would be a very difficult argument to make or or the common factor is the person, right? like you're the way that you're approaching things is not is not great. So again like if the tech lead hasn't been able to have that breakthrough like that's fine. Uh escalation of the manager I think makes sense. So uh you know I I wouldn't this is the kind of thing that like in my role as an engineering manager not this exact situation per se but this is the kind of thing that I have to deal with on a regular basis. I say have to deal with it sounds sounds bad. I mean these types of conversations like I don't I don't love them.

It's it's not you know I like being able to help. I like making sure that I can help unblock things, but you know, that's not necessarily an easy conversation to have, right? So, I don't look forward to that, but it's part of the job. So, um, okay. Got about 22 minutes left according to Google Maps, depending on how people want to drive in this lane, which is really bad. Uh, apparently, but about 20 minutes left. So, I wanted to talk about um rewriting code and refactoring and boy scouting and stuff. Um I'll try not to get too ranty. So, there are times and places for everything, right? So, uh you know, we'll try to add the disclaimer here, the the clarity that I'm not here to say never rewrite code, right? Code can never be rewritten. I'm not here to say never refactor uh as you go.

Um I don't like saying the words always and never because if I make a statement where I'm like never do this. If you have one scenario that disproves it and you're like but this is a scenario where it's a a good time to do that. It only takes one scenario to prove my statement incorrect. Right? So, it just it doesn't make sense to me. I don't I don't like saying always and never. I like saying, you know, it might be most of the time and then trying as best as I can to to qualify that with something. So, for me, I would say most of the time, rewriting stuff doesn't make a lot of sense. The pros generally do not outweigh the cons. And I would also say that I have found that um when people talk about refactoring as you go, I would say most of the time I have seen that be way more work than was intended.

Not always, right? I have mostly seen that be way more work than someone planned. I've mostly seen that spill over and cause people to to spend more time than they thought. I've mostly seen that cause more issues than people expected. Doesn't mean that it's never the thing to do, but when people make this the default, I'm like, hold on. Like, it might be the default for you because you are an experienced software developer. In which case, great. And like, truthfully, I'm not being sarcastic, like good for you. good for you that you're in a you're in a position where you can confidently refactor stuff. It's not going to balloon your timeline. It's not going to put your code at risk. Like truthfully, good for you. That's a great spot to be in. I think that that is the ideal state to be in, right? Where you have code that is structured in a way and your skill level is such that you are able to go refactor it.

You're not changing the behavior. You're cleaning things up, right? You can make things more testable. You can add the tests if they were missing or enhance them, whatever it happens to be. And you understand like the time implication of doing that as well. You know, those are all awesome things. Truthfully, you made things better and had at least understandable time impact, right? because obviously if you're going to be doing extra work, it's going to just take extra time, but that might be worth it, right? So great. I just don't think from my experience that this default mode is something that I would encourage. And the reason why is that I don't think most people that I've worked with fall into that category of all of those things working well. I just have not seen that.

And maybe that's been my lived experience and like I'm the outlier that I've just happened to be in places for the past, you know, whatever 13 years where I see people that happen to be spending more time on this stuff, breaking more things that they expect, causing more problems just because they wanted to go reorder a couple things. like I I rarely see that work out the way that people expect. So I don't like it being the default and what I'm describing is actually rewriting, not refactoring, just for the record. Okay? And this is why I was trying to introduce this earlier that historically when people say I'm I'm trying to use like terminology that gets dropped in practice, people will say there's tech debt. We need to go refactor this code. Okay, this code this code isn't testable. We need to go refactor it. You might be sitting here raging going, "That's not refactoring.

That's rewriting it." And I'm whatever. Right? I'm just saying that people will say that this is my plan. I want to go refactor this or we need to refactor it. And they genuinely might have the intention to not be changing behavior genuinely. So they might actually mean refactor. But what happens a lot of the time is that this extends well beyond just a quick refactor. I have seen this kind of stuff. Not only it's like it's one thing to go refactor and introduce a bug and then you're like, you know what? At least now it's way more testable and we can go add a a test case on on whatever you know escaped. Like oops, sorry we missed that. But great news, we refactored it and now it's actually really easy to test. Like that's that's not so bad, right? Depending on what the bug is.

What's way worse in my opinion, maybe not depending on whatever the bug is, but what what could be way worse is the situation, and I've seen this happen an unfortunate number of times where someone goes, "We just need to refactor this. It's probably just going to take an extra day or two of work, but then, you know, but then we'll be in a good spot, right?" And I'm just making up the numbers, whatever. But then what ends up happening is that this refactor turns into like a multi-week, multi-month rewrite. And again, I I hear the comments. I hear them where someone's going, "Well, someone should have stopped that like that. Isn't that why you have standup meetings? Isn't that why you have project managers? Isn't that why there's a team to stop that from happening?" Yeah. Yeah, it is. like we have all those things, we have all these preventative measures.

I have still seen this happen far too many times. I've seen someone who happens to, you know, articulate technical things in a way that a PM can't understand and basically bullies them, right? They basically steamroll the team. Well, that person's, you know, that person's the more senior person. They're smarter. We should just trust what they say and then it happens. I'm not saying that there aren't supposed to be checks in place or this isn't an addressable thing. I'm just saying in practice. I've seen this happen far too many times. So, in a nutshell, you know, when you're rewriting swaths of code, this is absolutely going to destabilize things. And I don't care how many tests you have, it's going to destabilize things. So, no, your go-to should not be, I'm touching the code, I guess I better go rewrite it. or I'm touching this code. I guess I better air quotes refactor this whole thing, right?

That's not it shouldn't be the default. And like I said, if it is should be having conversations because maybe your codebase is in such bad shape, right? Even I'm trying to think like what scenario would I would I encourage that? And I'm thinking like even if you had a team, okay, new new team forming and at the same time somehow they inherited some legacy codebase and no one is around from the legacy codebase. You got this code. Do you just start rewriting it? Like got to go do this thing. Guess I'm rewriting it. Like I don't know, man. It seems like it's almost risky. like does it not? You don't even know it. You don't even understand it and you just want to go start rewriting it. Like maybe. But I I would say expect things to break, expect to lose functionality. And I'm not saying that that's not I don't know like it can't be net positive.

Like maybe the code is so bad. Maybe there's other broken too. I'm not saying there's no situation where that can't be net positive, but I'm just saying like expect that you're going to have lo loss of functionality. Something's going to be missing. Statistically, it must. People don't know what's actually there. Now in my head I'm like, "Okay, you got a few minutes left before you're home. Can you talk say something positive about rewriting stuff?" No. No, I can't. No, I'm just kidding. Um I think yeah, like there's when it comes to rewriting stuff, I just think the biggest thing is like you need to be honest with yourselves, right? Like expect that there's What's going on here? Come on. Sorry. This person's not driving and it's driving me nuts. If you turn right here, I'm going to lose my mind. Good. Okay. Um, I think if you're going to rewrite stuff, you have to be honest with yourself that like there's going to be a loss of functionality.

And you might be saying like, look, we've already identified the core functionality that we're tracking and that needs to be there and we're aware of it and we actually don't care if the other stuff breaks or isn't there, right? Maybe like I'm just thinking about a user interface, right? There might be stuff that's legacy. There's like hidden stuff in context menus and you're like whatever, we're just rewriting this thing. And now you have a user that's like, "Dude, where did that rightclick context menu go in that like triple nested submen? I use that thing all the time." And you're like, "We didn't we didn't even know that existed. That's from 10 years ago." You might be totally okay with that. And I'm not saying that's wrong. That could be absolutely the right thing for your business and team to be doing. Totally. And I'm not being sarcastic.

That might be the right thing. I just think that you need to acknowledge that, right? Like I think it's the the worst thing the worst thing is going into a rewrite and that just expecting that you're going to cover everything, that you're going to reach parody. You will not. It's not going to be at par. It just like it I don't know. I haven't been doing this my whole life, I guess. So, there's that. But I have never seen a rewrite that reaches parody. And I'm not saying that that's a bad thing. I can say that we did I we didn't a lot of us didn't want to, but we did. We did a rewrite at the startup that I was at. This was uh technically the first rewrite was when we took it from the founder and converted languages going from VB6 to C. That was a that was a rewrite.

Technically, it was a port, but it it automatically generated code and we basically had to rewrite it. So, there's that. And the first thing I did at that company was I actually wrote from scratch uh one part of the application, right? So, like technically that was I guess like a rewrite. So, oh no, like I'm Nick's breaking his rule like don't rewrite things. I'm not saying don't rewrite. So the amount of features at that point and to be honest this wasn't even a factor at the time. I would have been so junior and we would have been such an early stage startup that like I don't think anyone was really thinking about this. We just knew that it couldn't have existed the way that it was. So we said you know we'll go rewrite it.

Um later on a few years later, you know, when the company was definitely grooving along a little bit better and we had more engineers, we reached a point where there was a decision where people were saying we can't scale this product the way we'd like to. The way that we have things set up currently just will not enable us to do that. I think ultimately my opinion is it was more mostly like a data schema kind of thing. I think and um and then we had like legacy code that was like crappy to work with but I think a lot of us were like let's update let's migrate the data schema and like let's start peacemealing this thing and like let's get it converted over to be whatever and ultimately the decision was made where it was like no we're just going to rewrite it from scratch and we were like ah okay um and it was hell it was absolute hell it succeeded did.

So, like I'm I'm not saying like in hindsight was that the wrong thing to do? Maybe it was the wrong thing to do. Maybe peace meal, you know, rewriting like a what do you call it? Um like strangler fig approach where you're doing mini uh rewrites and replacing the pieces over time. Maybe that would have been better. I don't know. Like I don't have a time machine. I can't compare them. In the end, things were successful. So that's the metric we have. That's what we have. But I can tell you along the way there were so many things where we were like, "Oh yeah, what about that feature? Oh yeah, what about that feature?" There were like there were just like an uncomfortable number of things where we were like, "Oh shit." like what are we going to do about that? Like do users actually use that?

And it's like someone uses it. Guaranteed someone uses it. And there was there were things like years after that where someone was like I I miss this about the old product. And we were like, "Oh, what is that?" Um so anyway, it's not never do it. I just don't think it's the thing you want to lean into as the first choice. And uh if you're going to do it, just accept that you're going to have parody gaps. That's okay. Thank you for coming to my TED talk. If you thought this was helpful, um share it back to Reddit. Share it somewhere, please. And thank you. I appreciate it. And then someday I can drive in the fast lane and afford it. See you next time. Take care.