本文由 AI 分析生成
建立時間： 2026-03-23 來源： https://www.seangoedecke.com/bad-code-at-big-companies/
Summary
Sean Goedecke argues that bad code at big tech companies is a systemic output of deliberate organizational choices — short engineer tenures, high internal mobility, and a preference for legibility (fungible engineers) over expertise — not individual incompetence. The root cause is that engineers are systematically assigned to codebases they don’t understand, and the organization is structured to keep it that way.
Sean Goedecke 認為大型科技公司的糟糕程式碼是刻意組織選擇的系統性輸出——工程師任期短、內部流動率高，以及偏好「可讀性」（可互換工程師）而非專業知識——而非個人無能。根本原因是工程師被系統性地分配到他們不了解的程式碼庫，而組織結構旨在維持這種狀態。
Key Points
- Big tech RSU vesting structures incentivize 1-2 year tenures; services live 10+ years — result is perpetual beginner ownership
- A large fraction of code changes come from engineers who’ve been in the codebase < 6 months
- Companies deliberately trade code quality for legibility (ability to rapidly reassign engineers across codebases)
- Senior engineers are overloaded with reviews and can only provide shallow feedback
- “Pure engineering” (self-contained, expertise-driven) vs. “impure engineering” (deadline-driven, unfamiliar systems) — big companies force the latter
- Making engineers individually stronger doesn’t fix this — the problem is structural, not individual
Insights
- The “legibility vs. expertise” framing is the sharpest part of this piece. Most criticism of big-company code quality implicitly assumes the problem is hiring or skills — Goedecke’s point is that the org structure would produce the same output even with better engineers, because the system’s incentive is fungibility, not mastery
- The 1-2 year tenure observation explains why so much enterprise code has the same archaeology pattern: you can literally read the org’s hiring waves in the commit history, each layer written by people who’d just arrived and would soon leave
- “Pure engineering” as a category is useful but slightly romanticized — even language designers and open source maintainers face impure pressures (funding, community politics, deadlines). The real distinction is probably degree of codebase ownership over time
- The 2025 power imbalance note is important context: the article acknowledges engineers can’t change this individually, which is honest but also a bit defeatist. The counter-argument (which the piece doesn’t make) is that some companies do successfully build expertise retention — it requires deliberate org design, not just hiring
- This connects to the “technical debt as org debt” idea: bad code isn’t a technical problem, it’s an organizational artifact. You can’t solve it with better linters or code reviews — you have to change how people are assigned and retained
Connections
Raw Excerpt
Making every engineer twice as strong wouldn’t solve the problem — the root cause is systemic assignment to unfamiliar codebases.