How good engineers write bad code at big companies

Original Article ↗ Hacker News Discussion ↗

Architectural patterns & overengineering

  • Some commenters push back on “drive-by attacks” on CQRS/DDD/TDD, arguing they’re useful patterns when applied pragmatically, but often turned into dogma that drives needless complexity.
  • The article is seen by some as conflating “pure engineering” (reducing systems to cohesive concepts) with “architecture astronaut” overdesign, which they view as opposites.

Primary causes of bad code

  • Many argue the main driver is rushing to meet deadlines and shifting or ill-defined requirements, not lack of skill or unfamiliarity with the codebase.
  • Short-term incentives (shipping features, promotions, looking good to management) routinely beat long-term code health, even when this hurts delivery speed later.
  • Some claim the worst code comes from unstable foundations and constant requirement changes; others say that’s exactly where responsible engineers should push back, but doing so is often punished.

Seniority, expertise & tenure

  • Debate over whether a good senior can “avoid bad code from day one”: critics say “good” is contextual and deep understanding of a large codebase simply takes time.
  • Institutional knowledge is seen as undervalued; frequent reorgs, fungibility, and layoffs destroy expertise and encourage shallow, duct-tape solutions.
  • Some dispute the article’s “1–2 year tenure” framing as misleading, noting growth effects and citing longer real tenures in some big-tech teams.

Business incentives vs code quality

  • Repeated theme: management doesn’t know how to assess code quality, only visible outcomes (features, metrics), so maintainability and refactoring are deprioritized.
  • Engineers who ship quick-and-dirty code often get rewarded; those who invest in cleaning things up struggle to justify it unless they can tie it directly to revenue, churn, or roadmap acceleration.
  • Others argue “bad” or “ugly” code is often economically rational “good enough for now,” analogous to cheap but acceptable physical products.

Process, culture & management

  • Many anecdotes of refactors blocked (“too late to change”), legacy schemas frozen due to fear of breaking changes, and architecture decisions never revisited.
  • Code review culture is criticized for fixating on style/naming while ignoring design/requirements and big-picture correctness.
  • AI assistance is seen by some as amplifying the volume of syntactically correct but conceptually poor code, especially in the hands of “tactical tornadoes.”

Craft, motivation & burnout

  • Several commenters describe a trajectory from caring deeply about code quality to nihilism: realizing the organization neither rewards nor protects that effort.
  • There’s tension between seeing programming as a craft (like fine cooking) versus as production work (bricklaying under time pressure); most agree some compromise is inevitable, but feel current incentives are skewed heavily against long-term quality.