Code Quality Shouldn't Have a Bus Factor of One

The senior-most engineer I worked with at Past Company had exacting standards when it came to the low-level craft of writing code. Let's call him Tight Typing Tim.

Tim kept a close eye on pull requests across the entire codebase, and would consistently call out any corner cutting. Slightly imprecise with your type hints? You gotta fix that. Ignoring a lint warning? You better have a solid justification as to why.

"Aren't there more important things for Tim to focus on?", I would occasionally ask myself. After all, this is a high-growth startup facing countless technical challenges. Surely Tim should be concentrating his time elsewhere?

But then Tim left the company, and suddenly, there was no one with the authority to uphold the coding standards that he originally helped instil. Gradually, the type hints got sloppier. The # pylint: disables proliferated.

Once the prevailing attitude shifted from "this exists for a reason" to "this is friction unless proven otherwise", the rest went quickly. Test coverage requirements started to look negotiable. CODEOWNERS started to look bureaucratic. Design reviews started to look optional. The engineering org had stopped treating quality safeguards as part of engineering, and started treating them as paperwork.

Hunt and Thomas describe this in The Pragmatic Programmer as the broken windows theory applied to code: one tolerated compromise becomes permission for the next. And the standard advice is simple - don’t tolerate the first compromise. Everyone nods along, and then everyone watches it inevitably happen all over again.

The broken windows framing, while not wrong, misses the deeper problem. The issue at Past Company wasn't that we tolerated the first broken window, but rather that our code quality had a bus factor of one. Tim's standards weren't the team's standards - they were his. Even while Tim was present, his role risked tipping into being the senior-as-bottleneck, as the person who blocks your PR, as the obstacle to shipping. Tim was right about almost everything, but it’s not enough for rightness to sit in one person’s head.

So the question shouldn’t be "how do you prevent broken windows?" - it's "how do you make the windows structurally hard to break?"

Automated checks are the obvious first line of defence, by obviating the need for any one person to play enforcer. But my story shows that if there isn't genuine buy-in, people won't respect the checks, and they will route around them. Automation without understanding is just friction.

The harder problem is that genuine buy-in mostly comes from experience. Teams that have spent a week untangling a bug from ambiguous interfaces, missing tests, or undocumented assumptions develop a visceral respect for the practices that prevent those outcomes. War stories are one of the more underrated forms of institutional knowledge.

But this creates an uncomfortable catch-22. If your standards are high and your systems are healthy, the team never accumulates the scar tissue that makes them care about keeping it that way. Quality, maintained well, is largely invisible. Tim was the institutional memory, who carried the war stories and the context for why each safeguard existed and what the codebase looked like before they were in place. When he left, that knowledge left with him, and without it, each quality check looked like arbitrary overhead.

So what actually makes standards durable?

The answer is distributed ownership. Rather than concentrating the defence of quality in a single person, you need multiple engineers across the team who internalise and model these standards. Pushback on a sloppy PR should come from anyone and everyone - not just one vigilant senior. New joiners should be onboarded into the reasoning behind the rules, not just the rules themselves. When ownership is distributed like this, standards stop being one person's rules and start being the company’s values.

This only works if the processes themselves are worth defending. Part of what made it so easy to dismantle CODEOWNERS and the design review process was that, by the time they came under attack, they had stopped serving their original purpose. Reviews had become rubber stamps, and the processes had become ceremony. The right response isn't to delete these things, but to fix them. Make the reviews substantive, make the design docs proportional to the change, and revisit the rules when they stop making sense. Processes that a team actively maintain and believe in are far more resilient than ones that exist by inertia.

The job of a senior engineer isn't to be the permanent guardian of quality - it's to make the standards survive your absence. If you leave and nothing changes, you've done the job properly. The irony is that no one will notice.