Your codebase is not a museum for old code

Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron.

Joel, why won't you just delete your code? Just delete it. Just delete your code, Joel.

Just highlight it, delete it, commit. I don't want to even see it anymore, Joel. Get it out of here.

I am being targeted here unfairly, but I know where you're coming from. And, Aaron is diplomatically yelling at me because we're friends,

and I will take it. But the reality is, this is a thing that we bump into a lot, and we will protect the names of any innocent.

You know, if you've worked with us and you're listening to this and you think we're talking about you, we might be.

But we're probably also talking about everybody else we've worked with, so don't take it personally.

But anyways, to the topic at hand. Your exasperation at not deleted. Okay, so let me set this up.

So, you're, "Hey, Aaron, I need you to work on this controller. We want to update something." And, "Can you go refactor this?"

And then you open it up, and there's 75 lines of commented-out code.

Well, you know that's just the smell. That's great, that's obvious. I'm going to talk to you about something that is the real reason why this drives me nuts.

Okay, let's dig into it.

Let's talk about the difference between you're in a project forever, versus you're hiring on a new developer, versus you're hiring on consultants. Right?

Yes.

So, there's a lot of context, there's a lot of stuff built up in your project. I understand that, I get that. That's valuable, that's necessary.

That's something all that history stuff that maybe even AI tools can't figure out now, and we don't want to lose that.

But that's in the person, that doesn't necessarily need to be in that code.

Okay.

Now, the reason why I run into this issue is. So, let's just say you're coming into a new project, or it's a section of the

code base you haven't really worked with before, and someone says, "I need you to update the FightFires component."

And, "We're fighting fires now. V2 has to have the garbage can on it." I'm like, "Okay." So, the first thing I'm going to do is

I'm going to search for FightFires, I'm going to search for garbage can, like in the code base because I don't really even know what most of

those things mean. Like, I get it. I can kind of figure it out, but I want to see the code patterns. I want to see, like, is there any other

garbage can icons? Because I think that's what you mean. You know, if everywhere else has a garbage can icon and then there's just

like one delete button on the component I'm looking at, I get it. You mean you want to have that delete turn into a garbage can?

Perfect, makes sense. Now, here's the problem. When I do that search and I run into 37 results,

I'm like, "Oh wow, there's a lot of garbage cans and there's a lot of FightFires around here."

And I'm starting to look through this in my editor, or however I've done my findings, I'm like, "Oh. Well, okay, so I've searched out."

I'm trying to do the pattern, there is 27 garbage cans, and there's 6 delete buttons. Well, okay. Now, there isn't 6 delete buttons,

there's only 1 delete. Why do I think there's six? Oh, because all the other ones that I found above it and below them are commented out.

But in my search I'm just finding a line where it says the label is garbage can. So, again I have to look at each one of those even further to figure out,

"Well, is this even in use? Is this code in use?" Turns out I found 27 and 6. Really, I found 27 and 1, because the other one should have

just been deleted, so I didn't find them again in my search. So, that's just the basic idea, you know. And then if you want to extend that further.

It's like, okay, well, what is the FightFires module? Well, there used to be an old one that we just commented out, we're just it keeping around for later.

No, that's what you have Git for. If you want to find it, you can bisect to find out when you've removed it. You can do all these different things.

So, I know I've just kind of rambled on here, but I wanted to make sure that it's not about seeing the code commented out.

Yeah.

That's ugly, but I don't really care about that. I care that it's slowing me down when I'm trying to solve something for you.

Yeah. And I'll even go one step further, because I've experienced that pain. Sometimes that V1 module isn't even commented out, just nothing calls it.

Right? It's still in the folder. It looks like a real component, same thing. You know, we're talking components. It could be controllers,

nothing's wired up to it. There's no routes wired up to it, nothing else is calling into it. So, it really looks like real code,

but you need that extra knowledge or that extra time, which is what you're talking about, to go figure that out. And we're just trying to save

you money if you're hiring us, right? You want us to be more efficient. Like, this might sound like we're being selfish. Because, Aaron, I'll admit.

We probably join more projects than maybe the average Laravel developer listening to us complain right now, right?

Mm-hmm (affirmative).

Because that's the nature of our work, we join projects. But I think we can make the case too like. Even if you're on that team day in, day out,

it's slowing you down and it's confusing you, too, right? I mean, this isn't just about us. Like, we're exasperated but we feel the pain maybe more acutely.

But it affects the team too.

Well, and kind of like I alluded to. I mentioned AI in those things in general. What I've just seen is I just described what I would do before AI.

So, I did searches and stuff. Well, no, AI is doing that searching. And yeah, maybe it's smart enough to search a couple lines around it, but maybe it's not.

Maybe it doesn't know that, you know. So, you're not only slowing down yourself, you're burning up more tokens if you're into that sort of thing.

You know, you're costing yourself more money because this agent is going to find all those different things and have to determine that,

"Oh, those are not in use." The other thing I run into is like security updates and stuff. Like, okay, well, we have this library,

and an automated scanner found it. Well, turns out no one's actually visiting that, and yeah, it is a problem. But it shouldn't even be a problem

because all that code should be deleted.

Right. Yeah, there's all sorts of liabilities and things here. So, in the midst of your eloquent ramble, you threw out the words 'git bisect'

and I think it's worth talking about that a little bit more. Like, the biggest pushback I've gotten from people about not deleting dead

or commented out code is like, "I want that as a reference. I want to find it, I might need it later." And I always like, "Well, you have Git.

That's like why we have this." But then the follow-up question is like, "Well, how do I find it?" Like, "I don't know what to do," right?

So, Git bisect is the tool. Do you want to talk about that, or do you want me to riff on it a little bit?

Well, you jumped ahead a little bit there. Is, more often than not, the pushback is not, "How do I find it?" It's just more guttural than that.

Like I say, "Delete this code," and the person says, "No, because I need that code." Like it doesn't, "How would I ever find it again?"

They haven't gotten that far. And when you say Git, it's like... Well, then you mentioned Git, it's like, Oh, well, then it's difficult to find inside of Git.

I get that. But the first step is, if someone says to you, "Hey, there's something I want you to change."

The answer isn't, "No, I can't". It's like, "Oh, tell me some alternatives, some options to that. Okay, I get it.

I don't understand your point of view right now. I don't see why you're trying to tell me to delete this code.

But what would I do in this case then, when I need to find that again? I'm willing to delete this code because you're saying it's a good idea,

but what would I do?" See, that's a totally different conversation, and it allows someone, you know, a senior developer, to teach you, or whatever.

Yeah, I agree. And, yeah, like you're saying, maybe... And, it's like a pattern that's been so well established in your project,

and maybe you don't even feel like it's slowing you down. So, like, what's the harm, man? Just leave it there.

Yeah.

But, like you said, open mind. Okay, thought experiment, what if I did delete it? And what if I did actually need it?

Which you probably won't, but that's beside the point. How would I find it? And that's like the next logical place to take it.

But, yeah, you're not shutting that door.

I would also say I'm sure everyone in the world is going to argue with me when I say this. But I have never really that confidently seen

something that I've commented out, and then a year later, looked at that code and been like, "Yeah, I need that."

Because the project now moved on so far past that. And also, you're learning, if you're a good developer, which everyone who is listening

to this podcast probably is. You've learned how to do stuff better, so that code isn't how you do it anymore.

And maybe that business domain isn't the same anymore. So, you probably don't need it, you're just being paranoid. But if you do need it,

there's Git bisect, or there's Git log, and all that kind of stuff. And Joel, you can talk a little bit more about it. I'm just talking so much here,

and no one wants to hear me ranting even more.

First of all, I like your pandering. How you said that everybody listening is a smart developer. Well played, I like that.

Yeah, I'm not going to get deep into the weeds. But Git bisect is like a way of searching a commit history in an efficient manner.

Where I think it picks like a halfway point between... You know, if you said, like, "Hey, in the last year I'm looking for this piece

of code that was deleted." You'd have to create a little test to say, like, "Well, what was the name of the method you think?

Or the file name?" And then Git would run that for you, and kind of jump to the midpoint. "Was it there? No. Okay, I got to go back further,"

and it would do all this work. But honestly, I think now, especially with these fancy coding agents we have, it can do that work for you.

Like, you don't even have to know how Git bisect works effectively. You just need to know it's a thing, and then you can ask Claude,

or whatever you're using, to go do that for you and find it for you. And I actually did this as an experiment.

Like, there's a tip I wrote up about it on Mastering Laravel, if you really care to go find it. And it worked surprisingly well.

You know, I used one of these scenarios where there was something that was deleted, like in a project we had been on for a while.

And I just gave it, like, "I don't know when this was deleted. I don't know exactly what the file name was. Here's what I think it was."

You know, it was some change we'd made to, like, how Stripe worked, and it found it. It found it in, like, four minutes, right?

Right.

So, that proved to me that the argument we're making is compelling, especially with these coding agents.

Is, you can find that if you really need to find it, if you're using Git. And I hope you're using Git. I hope everybody's using version control.

Like, even if it's not Git, but it should be Git.

So, I want to make sure, though, that there's one little nuance that isn't lost here. I do, from time to time comment out code before

I've committed while I'm working through something. And so, I might have a block of code that I'm rewriting.

I might just rewrite it in place, or I might comment it out so I can see it on my editor and rewrite the code right below it.

But then I remove the commented-out code once I know it's working, or whatever.

So, I'm not saying that it's always horrible to comment something out. We're talking about keeping that for a duration of time.

Yes.

And I'm also not talking about comments being bad, either, because comments are great, they help you describe stuff.

I specifically targeted that. I think I might need this code later, but it's not running now, and I don't want it around.

Whether it's commented out or just like a menu item removed, and hopefully no one figures that out.

No, that's a good nuance. Because, yeah, we're not certainly not against comments, or the temporary...

I think you know, I do this sometimes when I'm writing tests. If I want to prove to myself I'm testing what I think I'm testing,

I'll actually go comment out like one line of code under test, "Watch my test fail." It's like, "Okay. All right, I am actually

testing what I think I'm testing." So, yeah, we comment stuff out all the time, just please don't commit it like that, right?

Yeah. So, overall, in general, obviously, I'm not that angry. I started out the podcast, you know, just yelling and rambling.

But it's a little bit for helping me, but it's a lot for helping the project, right?

Yes.

It's a thing that makes my job easier, but it's a thing I'd argue that makes everyone on a project's job easier as well.

So, reasonable. I love it.

I want to run you through a couple of common phrases and see what you think.

Like, the first one you just used there?

Sure. So, if I said, 'Hey, Aaron, have a nice day." Friendly, right?

Yeah. I mean, depending on your facial expression.

True. You could say it ultra sarcastically, but in general.

Or tone. "And you better have a nice day."

Right. But, yeah, if we just had a nice interaction-

Yep.

... we're about to part ways. "Hey, have a nice day."

"Thanks, Joel. You too."

I could go a step further. It's Friday, let's say, and I'm like, "Aaron, have a nice weekend," right? I'm giving you two days, I want you to have-

Oh, and possibly two and a half, because it's still Friday. So, thank you.

But now if I say, "Have a nice life." Is that just like inherently like rude, even though I'm like... You follow the logic.

I don't know, it just like I had that observation the other day, because I was with somebody, and they said, "Have a nice weekend,"

and it was Thursday. And they're like, "Oh, man, I'm an idiot." I said, "Have a nice week." I'm like, "No, you gave them an extra day.

And I'm like, "You could have gone all the way and just said, 'Have a nice life.'" But then, as I said it, I'm like,

'Oh, no, that would be kind of ominous." Like, am I right though? Like, I said, 'Hey, have a nice life."

It's like I'm never going to talk to you again, or what? Why is that bad?

Yeah, it sounds like a goodbye, or even... I mean, I constantly go to the threat level. "Have a nice life."

But, yeah, in general, it just sounds like, "Okay. Well, it was great to meet you, I'll never see you again. Have a nice life."

Like, the waiter at a restaurant over in a different country you'll never be to again.

Exactly. So, just use that with caution. I have yet to find a scenario where "Have a nice life" will come across good.

"Have a good decade, Joel."

Deleting code is awesome, and well, it's a little scary too. But it's not so bad if you have good test coverage.

Hey, we can help with that. If you want to get better at writing confident tests, head over to masteringlaravel.io,

click on courses, and check out our testing workshop.