Always Hunt for Orphaned Code After a Bug Fix

You find the bug. It’s a one-liner — the wrong array key was being used in a calculation. You swap it, tests pass, PR ready.

But you’re not done yet.

The One-Liner That Revealed Dead Code

After fixing a calculation that was reading from the wrong field in a data array, I asked a simple question: is the old field still used anywhere?

A quick grep showed it wasn’t. The entire block that computed that intermediate value — an assignment, a conditional, a helper call — was now dead code. Nobody else referenced it. The bug fix had made it obsolete.

What started as a 1-line insertion became a 1-line insertion + 8-line deletion. The codebase got smaller and cleaner.

Why This Matters

Every dead code block is:

• A maintenance trap. Someone will read it later and try to understand why it exists.
• A false signal. It implies the computed value matters. Future developers might wire it back in.
• A merge conflict magnet. It takes up space in files that people will edit for unrelated reasons.

The Post-Fix Checklist

After every bug fix, before you open the PR, run through this:

1. Search for the old value. If you changed which variable/field is read, check if the old one is still referenced. grep -rn 'old_field_name' app/
2. Trace the computation chain. If the fix changed a formula’s input, check if any intermediate variables in the old computation are now unused.
3. Check the callers. If you changed a method’s return value, verify all callers still make sense.
4. Look one level up. Sometimes fixing a bug in a helper method means the error-handling code that worked around that bug is now unnecessary.

A Real Metric

Some of the best PRs I’ve reviewed have more deletions than insertions. A bug fix that deletes more than it adds is a sign that someone actually understood the ripple effects of their change.

The fix is the minimum. The cleanup is the craftsmanship.