A one-line bug. I found it, I understood it, I fixed it. And then I stayed.
While I was in there the function looked messy, so I cleaned it up. Cleaning it up meant renaming a couple of things, which meant touching the callers, which made a small helper look redundant, so I inlined it. A colleague of mine used to narrate this exact spiral with a flat “one thing led to another,” usually right before a small PR turned enormous, and he was never wrong. Two days later I shipped a “one-line fix” as a 400-line diff, and my reviewer, reasonably, had no real idea what they were approving. They clicked approve anyway, because it was me and they trusted me, which is its own problem.
I was being a good citizen. Leave it better than you found it. The Boy Scout rule, Uncle Bob’s version of an old Baden-Powell line, repeated in onboarding docs and code reviews everywhere. It’s good advice. It’s also one of the easiest ways to quietly make a codebase worse, and I’ve watched good engineers fall into it as often as I have.
The Rule Is Real
Let me give it its due, because the rule exists for a reason.
The default state of code is decay. People leave, context evaporates, features pile on top of assumptions that stopped being true two years ago. If nobody ever improves anything they touch, the only direction is down. Treating a small mess as something you just don’t walk past, the way you wouldn’t drop litter, is a genuinely healthy instinct for a team to share.
So I’m not arguing against improving code. I’m arguing against what the rule turns into when you stop asking how much.
Where It Goes Wrong
The trap isn’t the cleanup. It’s that “leave it better” has no built-in size limit, so it quietly authorizes any amount of work as long as you can call it an improvement.
The bugfix that becomes a refactor
The story above is the classic one. You open a file to fix one thing, the surrounding code annoys you, and because you’re already here it feels efficient to fix that too. It rarely is. The fix was done in the first ten minutes. Everything after that was the available time inviting more work into the room, which is exactly the Parkinson’s Law pattern: the task expands to fill the space you give it, and “while I’m in here” is a very large space.
The “while I was in here” diff
A tidy bugfix is a 30-line PR someone can actually review. The same bugfix with cleanup bolted on is a 400-line PR they rubber-stamp. I’ve written about how big diffs wreck reviews in the CI post: once a PR crosses some size, the review stops being a review and becomes a vibe check. So your “improvement” doesn’t just risk the change you smuggled in, it weakens the scrutiny on the actual fix, which is the part that was urgent. You made the codebase prettier and the review worse.
Cleaning toward an abstraction nobody asked for
The most seductive version. You’re in there cleaning up, you spot three things that are almost the same, and you unify them. Now there’s a shared helper, a config flag, a base class. It feels like leaving it better. Often you’ve just added an abstraction the code didn’t need and made the next person’s change harder, which is the whole argument in A Case Against Abstraction. “Better” and “more abstract” are not the same word.
A Test I Use Now
The question I ask before cleaning anything up while I’m in a file: would this survive as its own PR?
If the cleanup, pulled out and titled honestly (refactor: simplify the X handler), would get reviewed and approved on its own merits, then it’s real work and it deserves its own PR. Open one. If it would not survive on its own, if the only reason it’s getting in is that it’s hitching a ride on an urgent bugfix nobody wants to block, then it isn’t improvement. It’s scope creep with a good story.
A few more checks behind that one:
- Do I actually understand this code? Don’t refactor what you don’t understand.
git blameand a quick word with whoever wrote it are cheaper than the bug you’ll introduce by guessing at intent. - Is it tested? If the code has no tests, your “cleanup” is a change you can’t verify. Either add the test first, which is itself the improvement, or leave it alone.
- What’s the blast radius? A local rename inside one function is nearly free. Touching a shared signature is not. The rule scales down beautifully and up terribly.
What Actually Fits
The version of the rule that works is the small one. The improvements cheap enough that they don’t compete with the change you came to make:
- A comment that explains the one genuinely confusing line, or deleting a stale comment that’s now actively lying to people.
- A single test, even a dumb one. The first test in a file is the expensive one to write; after that the setup is copy-paste. Leaving the first test behind makes the second one someone else writes nearly free.
- A local rename or an early return that makes one block read in the order it executes.
None of these blow up the diff. None of them need their own design discussion. All of them are reviewable at a glance. That’s the rule doing what it was meant to do: a small, honest, in-scope nudge in the right direction.
The Other Failure Mode
I should be fair to the other side, because “be careful with cleanup” has its own trap.
Take it too far and you never touch anything. Every mess becomes someone else’s problem, every TODO stays a TODO, and you tell yourself you’re being disciplined when you’re really just being scared. That’s how a codebase rots: not in one bad refactor, but in a thousand small messes that everyone walked past because it wasn’t “their” PR. Leaving it exactly as you found it is also a decision, and it compounds the same way deferred maintenance always does.
I’m not saying don’t clean things up. Clean things up at a size that’s honest about what you’re shipping. Small enough to review, in scope or in its own PR, understood, tested. The rule is good. It just doesn’t come with the word little attached, and that missing word is where most of the damage lives.
So next time you’re about to fix something while you’re already in the file, ask yourself whether you’d open this as its own PR. If the answer is no, you might not be leaving it better. You might just be making it bigger. One thing leads to another.