How Good Engineers Write Bad Code at Big Companies

Author: Sean Goedecke

Main Argument

Bad code at big companies isn’t produced by bad engineers. It’s the predictable output of organizations that deliberately prioritize engineer fungibility (easy reassignment) over expertise and code quality.

Why Short Tenures Create Bad Code

• Big tech compensation structures front-load initial RSU grants; engineers leave after 1-2 years before the full grant vests
• Internal transfers further reduce time-on-codebase
• Services live for 10+ years, but individual ownership rarely exceeds 2 years
• Result: a large fraction of code changes come from people who’ve been in the codebase for under 6 months

The “Old Hands” Problem

Experienced engineers exist but companies don’t systematically develop or retain them. Senior engineers absorb review load while also completing their own work — they’re overloaded and can only provide shallow reviews.

Deliberate Organizational Tradeoff: Legibility vs. Expertise

Companies choose to optimize for legibility — the ability to quickly reassign any engineer to any codebase. This enables rapid pivoting to new priorities. The cost is that engineers always work in unfamiliar territory, producing code that reflects that unfamiliarity.

This is not a mistake. It’s a choice that companies make consciously, because flexibility is more valuable to them than code quality.

Pure vs. Impure Engineering

• Pure engineering: self-contained technical work (language design, open source, research)
• Impure engineering: deadline-driven work on systems you don’t fully understand, constrained by org structure and politics

Big companies force most engineers into impure engineering regardless of their preferences or skill level.

Central Conclusion

“Making every engineer twice as strong” wouldn’t fix this. The root cause is systemic assignment to unfamiliar codebases. Individual engineers can’t change this dynamic — especially in the 2025 environment where power tilts toward leadership. The responsibility lies with organizational choices, not engineer failures.