The impact paradox: shipping more without progress
- YT :: https://www.youtube.com/watch?v=nXlCDGaStPg
- Original title :: Developers Who Solve the Wrong Problems Stay Stuck
Most developers aren't bad at coding, they're bad at deciding what deserves code - and that's where engineering output can rise while actual progress goes nowhere ("the impact paradox"). A lot of software failures are alignment failures, not technical ones: teams measure velocity instead of value and mistake architectural busywork for progress ("architecture theater") - microservices being the classic example, where one understandable problem becomes ten services, ten databases, and ten places for bugs to hide.
Citing the Standish Group's Chaos Report baseline, the video claims roughly 80% of software features are rarely or never used while 12% generate most daily usage - meaning most engineering effort becomes maintained dead weight ("dead code with a pension plan"). It also cites an estimate of ~$29.5B/year in cloud/SaaS waste among publicly traded cloud companies, with individual features costing $50k-500k to build and the opportunity cost of the alternative work not done running 3-5x higher than the direct cost.
"Resume-driven development" - choosing Rust, Kubernetes, vector databases, or a new frontend stack because they look good on LinkedIn rather than because they fit the problem - is named as a structural driver: every project has a finite "complexity budget," and spending it before the business logic even works is not ambition, it's setting that budget on fire. Boring, mature technology (Postgres, Django, a modular monolith) is framed as the senior choice precisely because its failure modes are known. AI intensifies this: it doesn't remove the problem of deciding what should exist, it makes it cheaper to ship more of the wrong thing faster, since agents optimize for completion of a given goal, not correctness of the goal itself.
The recommended posture: build the smallest thing that proves whether a problem is real rather than a "perfect" reusable platform; keep architecture modular so real domain seams can be split later once discovered, not designed speculatively; and become a "product-minded engineer" who asks what problem a feature solves and how success will be measured before asking how to build it. Technical excellence is a tool for outcomes, not the goal itself - sometimes the senior move is writing less code or killing your own solution once it stops serving the user.