We have a bad habit of treating every imperfection as an emergency.

When you find something that should be fixed in code, you fix it immediately. When you spot a typo in documentation, you correct it right then. When you discover a test that’s flaky but passes most of the time, you rewrite its timing logic. This reflex serves us well as engineers, and it drives everyone else absolutely insane. I have noticed it about myself for years now, and I still fight it every day — not because good code is wrong to want, but because we have confused thoroughness with virtue.

There is something genuinely valuable about leaving a thing broken. Not the kind of broken where you ignore critical failures or ship products that hurt people. The other kind: minor imperfections you notice when someone is looking closely at your work. A function that works but has an odd name. A test file with redundant assertions nobody would ever read in passing. A helper that exists only because a previous version of the code needed it, and hasn’t been deleted yet because deleting it would require one more commit than anyone wants to make right now. These are not bugs. They are artifacts — traces of decisions made under different circumstances, left behind when priorities shifted. And they should stay visible until someone decides that cleaning them up is actually worth the cost.

I think about this in relation to something I noticed while watching people do carpentry at a maker space last year. The woodworkers there had this habit of leaving rough edges on pieces not because they were lazy or unskilled, but because those edges told a story. You could see where a board came from — the tool marks, the way the grain was cut. A perfectly sanded surface lies about its origin. It disappears into a generic state that says nothing about how it was made. I realized that the same principle applies to code. When you sand every artifact down until your codebase looks identical to every other well-maintained repo on earth, you lose the evidence of what the code actually solved, for whom, and why certain compromises were necessary. A TODO comment next to a clever hack says more than a refactored version that has no explanation for why it exists.

The alternative is not recklessness. It is discipline about prioritization. Leave-behind items earn their keep through honest assessment: Is this thing making the next person’s work harder today? If yes, fix it — but mark it clearly so the cost of fixing is explicit. If no, let it sit. A broken test that will not run because its dependencies moved to a different service does not need an immediate rewrite. It needs a comment explaining what it used to prove and who would own it if those dependencies came back. That comment costs ten minutes to write and saves hours of confused digging three months from now. The craft is in distinguishing between things that hurt people right now and things that just make you slightly uncomfortable when you notice them.

This practice reshapes how I approach code reviews, too. When someone ships something with visible roughness, my first instinct was always to flag it as incomplete. Now I ask: does this roughness help or hurt the next person who reads this code? The answer is almost always helpful if it’s honest and unhidden. A function called normalize_input_for_legacy_api() that wraps a three-line transformation tells you something about the system’s history in ways that renaming it to transformPayload does not. The roughness was left on purpose, as evidence rather than embarrassment. That is engineering craft at its most pragmatic — understanding that clarity about imperfection is worth more than the polite fiction of completeness.