How Good Engineers Write Bad Code — A Hacker News Discussion

Hacker News discussions are my window into the soul of the developer community. The thoughtfulness and variety of high quality perspectives (as well as the absence of bots) really makes it one of the few places on the internet that I can trust. But it often happens that when a discussion hits 500+ comments, reading every single comment becomes quite impractical.

So I built a solution. My custom LLM client that I spoke about here includes a Hacker News web scraper that collects all comments from a discussion thread in structured format, then feeds them to an LLM with a specialized prompt. In the end I get an insightful digest that surfaces exactly what I care about: areas of consensus, key disagreements, and the overall pulse of the conversation.

This tool has become invaluable for navigating HN’s widely varying opinions and getting a quick read on where the developer community stands on any given topic. I set up an autocomplete shortcut that allows me to type “/hac” and the entire prompt populates automatically.

Press enter or click to view image in full size

The summary below comes from this Hacker News discussion about Sean Goedecke’s article on how good engineers at big tech companies end up writing bad code. If you haven’t explored Sean’s work yet I highly recommend it, his insights are always worth your time.

The following is all AI generated text based off that discussion and provides a really deep sense of how developers feel about their craft in an era where that craft seems to be diminishing in value.

🧭 Summary of Commenters’ Views

The central topic of the discussion revolves around why skilled engineers end up producing poor-quality code in large technology companies, inspired by the linked blog post “How Good Engineers Write Bad Code at Big Companies.” Commenters generally describe a system where institutional, managerial, and incentive structures — rather than individual incompetence — drive technical mediocrity. Common themes include misaligned incentives, organizational fungibility, short-termism, and the alienation of engineers from their craft due to corporate priorities and constant reorg churn.

The overall sentiment is one of cynical realism leavened by moral frustration. Many acknowledge the author’s descriptive accuracy about how corporate incentives and management dynamics produce “bad code,” but reject or lament what they see as a nihilistic or defeatist framing. Despite disagreement over whether resignation or resistance is “maturity,” participants widely agree that bad code is symptomatic of structural dysfunction, not a technical failing alone.

⚔️ Main Disagreements

1. Nihilism vs. Pragmatism

Argument 1 (sfpotter, stuffn, zmj, jeltz): The blog’s worldview represents a kind of “corporate nihilism.” It normalizes adaptation to inhumane systems rather than questioning their necessity. Good engineers are spiritually eroded by the routine of producing bad work under market forces. It’s not maturity — it’s despair disguised as pragmatism.
Argument 2 (alfalfasprout, kuahyeow, master_crab): The author isn’t espousing nihilism but descriptive realism — explaining how engineers must navigate tradeoffs and misaligned incentives to survive. Cynical though it is, this is practical wisdom, not philosophical surrender.

2. Why Engineers Care About Bad Code

Argument 1 (jagged-chisel, chii, brendoelfrendo): Engineers hate bad code because it directly harms them — it causes accountability problems, bad reviews, and managerial blame-shifting. It’s primarily a workplace survival issue.
Argument 2 (ajkjk, sfink, vloivich123): It’s deeper than that — bad code offends one’s sense of mastery and pride in craftsmanship. Engineers care because they see programming as art or engineering craft, not merely output. The pain stems from being denied that mastery.

3. Management’s Role and Competence

Argument 1 (asdfman123, hibikir, YZF): Management can’t evaluate “code quality,” so they rely on metrics and outcomes. The problem is epistemic: they simply can’t see the technical debt accumulating.
Argument 2 (pupatlas, BurningFrog, alfalfasprout): That’s an excuse — good management must understand engineering enough to value maintainability. Using ignorance as a defense only perpetuates bad incentives. Managers should either code or learn.
Argument 3 (YZF, hibikir, empiko): The rot comes from the top of organizations — CEOs and boards valuing shareholder optics and short-term gains over long-term technical health. Everyone downstream is just aligning to those incentives.

4. Is Bad Code Inevitable or Preventable?

Argument 1 (pxc, bmitch3020, jiggawatts): Even “bad” code often represents rational tradeoffs under time, cost, and uncertainty. Businesses don’t buy code elegance — they buy features. “Bad” is often just “good enough for now.”
Argument 2 (jeltz, hibikir, mikert89): No — many bad systems were bad even when written. “Good enough” is not a neutral compromise but a failure of professional standards and long-term vision. Engineering practice is supposed to resist such degradation.
Argument 3 (ford, jjmar, slygall): There’s a structural reason: startups optimize for speed and market entry, big firms overcorrect for bureaucracy, both paths incentivize code debt. It isn’t about the engineers’ willpower — it’s systemic.

5. Fungibility and Power

Argument 1 (Herring, zanellato19, cdavid): The fungibility of engineers is deliberate — capital suppresses expertise and collective power by rotating people to prevent dependency or solidarity. Efficiency is willingly traded for control.
Argument 2 (ford, elisbce): The “fungibility” charge is overstated; many firms work hard to retain senior expertise. Redundancy is sometimes a rational resilience measure, not a conspiracy against labor power.

🤝 Areas of Consensus

Misaligned incentives drive bad code. Across views, almost every participant agrees that organizational incentives — not technical ignorance — are the root cause. Performance reviews, metrics, and deadlines favor speed over sustainability.
Short-termism dominates large corporations. The quarterly-growth mindset and pursuit of share price trump engineering excellence or long-term planning.
Engineers feel alienated. Many describe the same emotional fatigue and powerlessness: corporate structures strip joy and autonomy from a craft that once felt creative.
Bad code is often an emergent property of scale and bureaucracy. Even good engineers succumb when teams are large, communication fragmented, or context constantly shifting.
Caring about code quality is both a moral and practical struggle. The tension between professional pride and pragmatic survival is universal.

💡 Unique Points of View That Really Make You Think

“Corporate Nihilism as a Defense Mechanism” (stuffn): A powerfully existential observation — engineers start idealistic, viewing code as personal art, but corporate systems “beat that out” until nihilism becomes emotional armor. Burnout is reframed as ideological collapse.
“Capital Trades Efficiency for Control” (Herring, zanellato19): Large organizations consciously accept lower productivity by rotating engineers to avoid concentrated technical or political power — a structural safeguard against labor leverage, not an accident.
“The McNamara Fallacy of Code Quality” (tehnub, pupatlas): The inability of management to measure code quality leads them to optimize only what’s quantifiable — a mirror of the Vietnam-era fallacy of measuring progress by body count.
“Sandbagging as Survival Strategy” (JohnMakin): In toxic performance-ranking systems, strategic manipulation of throughput metrics (slowing or speeding delivery) becomes a political act that indirectly fixes organizational priorities — an unsettling but realistic adaptability.
“Artists vs. Bricklayers” (pxc, britch, viraptor): An illuminating thread likening programmers to either craft artists seeking elegance or industrial cooks/bricklayers meeting deadlines. It reframes the debate as an occupational identity crisis between engineering as art and engineering as production.
“Better Than You Found It Principle” (jeltz): In degraded systems that can’t be rewritten, the pragmatic moral code is incrementalism — clean a little, don’t worsen what you touch. This ethic of micro-improvement replaces idealistic rewriting with sustainable stewardship.
“You Don’t Hire Master Engineers — You Manufacture Them through Stability” (kcexn): Large firms privilege repeatable mediocre processes over exceptional individuals because business scalability depends on predictability, not brilliance — a sobering inversion of “great man” engineering myths.