We are destroying software

Overall reception & tone

• Many see the essay as emotionally resonant but rhetorically over‑the‑top: more a crafted rant than an argument with clear solutions.
• Some read it as a useful “wake‑up call” about culture and long‑term consequences; others call it nostalgia, cynicism, or “old man yells at cloud.”
• Several argue the critique is heavily skewed toward Silicon Valley–style web development and doesn’t reflect the entire industry.

Reinventing the wheel, rewrites & backward compatibility

• Commenters highlight tension between:
  • “Don’t reinvent the wheel” vs encouraging learning by re‑implementing things.
  • Preserving backward compatibility vs avoiding ever‑growing complexity and lock‑in.
• Some say the industry has over‑indexed on “never rewrite,” others that SemVer culture normalized breaking APIs and forces constant, painful upgrades.
• Consensus: both rewrites and reinvention are sometimes right; the damage comes from applying any simple rule universally.

Complexity, dependencies, and the modern stack

• Many agree software systems have become bloated: deep dependency trees, fragile build systems, containers everywhere just to run “simple” services.
• Web and npm/Electron stacks are frequent examples of accidental complexity that’s easy short‑term but hard to keep running for 10–20 years.
• Pushback: abstractions are how we scale; lower‑level isn’t automatically “better,” and demand for distributed, mobile, secure, integrated systems really has grown.

Business incentives & engineering culture

• A recurring theme: it’s less “engineers destroying software” and more business models that reward speed, feature count, and “impact” over robustness, simplicity, and maintainability.
• Resume‑driven development, job‑hopping, metrics gaming, “move fast and break things,” and under‑valued documentation are all seen as systemic symptoms.
• Some note that quality is often rationally traded away when products or companies may not exist in a few years.

Longevity, quality, and performance

• Several argue we write too much short‑lived, hard‑to‑maintain code, and too few people ever see the long‑term consequences of their design decisions.
• Others counter that not all systems need to last 30 years; many business domains change faster than that.
• Strong minority concern about loss of performance‑minded craft and the normalization of slow, buggy software as “good enough.”

AI & the future of programming

• The post’s request to “remove AI from the ledger” is contested. Some say recent life improvements (delivery, streaming, digital services) don’t require today’s complexity; others insist overall welfare has clearly improved.
• On AI tools: some see them as accelerating the same cultural problems (less understanding, more code churn); others see them as a way to strip away tedium and refocus on design and outcomes.