Software engineers don’t get promoted for deleting code. And that’s destroying software. A viral article on terriblesoftware.org (published March 3, 2026, currently #1 on Hacker News with 149+ comments) crystallizes what developers have known for years: promotion systems reward unnecessary complexity while ignoring the value of simplicity. Engineer A ships a straightforward 50-line implementation in days. Engineer B spends three weeks building pub/sub systems and configuration frameworks for hypothetical future needs. At promotion time, Engineer B’s work documents as impressive “technical leadership” while Engineer A’s superior solution lacks a story. This is Promotion-Driven Development—and it’s a leadership failure.
Promotion Packets Reward Complexity, Not Business Value
Most software engineering promotion criteria measure “impact” by the size and scope of what someone built, not what they avoided. Complex architectures generate compelling narratives—”designed scalable event-driven systems with pub/sub messaging, comprehensive monitoring infrastructure, and automated rollback mechanisms.” Simple solutions disappear into three words: “Implemented feature X.” This creates perverse incentives where engineers optimize for impressive-sounding packets over actual business value.
The real-world consequences are absurd. One engineer created a complex platform with zero adoption yet got promoted from senior to staff engineer because the project met “architecture/design competencies” expected at senior+ levels. Business impact didn’t matter. Meanwhile, engineers who ship pragmatic 50-line solutions in days—delivering faster time-to-market and reduced maintenance burden—have no compelling promotion narrative. The system rewards what looks good on paper, not what actually works.
Related: Boring Tech Stack Wins 2026: Why Devs Ditch Complexity
How Complexity Gets Baked Into Career Advancement
This problem flows through every stage of an engineer’s career, creating a self-reinforcing culture of complexity. It starts in interviews. Candidates who propose simple solutions face immediate pushback: “What about scalability?” They learn that adding complexity impresses interviewers more than demonstrating judgment about when complexity isn’t needed.
Design reviews make it worse. Engineers get pressured to “future-proof” systems, leading to abstractions for hypothetical problems rather than actual requirements. Questions like “Have we thought about scale?” put the burden of proof on simplicity. Complexity becomes the default expectation, pragmatism becomes the exception you must justify.
Then comes the promotion committee. At companies like Google and Meta, committees see packets without full business context. A 50-line solution looks trivial unless you explicitly explain what complexity you avoided—and most engineers don’t know they need to do that. These companies require “demonstrating next-level work for 6 months,” but simple solutions don’t generate the architectural diagrams and dense design docs that signal “staff engineer material.”
The result: junior engineers observe who gets promoted and model their careers accordingly. They optimize for technical complexity over clarity, individual brilliance over team success, being right over being helpful. The cycle perpetuates itself because the incentive structure demands it.
The Business Cost of Broken Incentives
Promotion-driven complexity has measurable costs. Simple solutions ship 50-80% faster—two days versus three weeks in common examples. Yet complex architectures require 3-5x more operational overhead. Refactoring from simple to complex (when actually needed) costs less than maintaining unnecessary complexity from day one. In 2026, 67% of developers report increased pressure, partly from the maintenance burden of over-engineered systems that didn’t need to exist.
One engineer’s example: choosing a simple REST API over event-driven architecture saved 2.5 weeks delivery time, accelerating $150K in revenue. The simple solution had 100x headroom for current traffic (10 req/s versus 1,000 req/s capacity). However, that pragmatic decision wouldn’t help a promotion packet—no impressive architecture diagrams, no complex design docs, just shipping value fast. The incentives are completely misaligned with business outcomes.
How Engineers Can Make Simplicity Visible
Engineers can fight back by making simplicity promotion-worthy. The key is explicitly documenting what complexity you evaluated and rejected. In design docs, add an “Alternatives Considered” section. List complex alternatives—event-driven architecture, microservices, custom frameworks—and explain why you rejected them. Moreover, quantify trade-offs: “Evaluated event-driven architecture but rejected because current traffic is 100x below threshold, implementation would add three weeks, and we can refactor later if we hit 500 req/s sustained.”
Define specific signals for when complexity becomes necessary. Make decisions evidence-based: “The signal to watch: if traffic exceeds 300 req/s for seven consecutive days, revisit architecture.” Furthermore, this makes simplicity the default and puts the burden of proof on complexity, where it belongs.
Work with your manager. Don’t assume simplicity speaks for itself. Ask directly: “How should I represent this decision in my promotion packet? I chose simple over complex, which accelerated delivery by 2.5 weeks and avoided operational burden. How do I make that judgment visible to the committee?” Most managers want to help—they just don’t realize simple solutions need explicit framing.
Leaders Must Fix the Incentive Structure
Individual tactics help, but this is ultimately a leadership failure requiring structural fixes. Engineering leaders must explicitly reward simplicity through changes to design reviews, recognition systems, and promotion criteria.
Start by shifting design review questions. Instead of “Have we thought about scale?”—which puts burden of proof on simplicity—ask “What’s the simplest version we could ship, and what specific signals would tell us we need something more complex?” This makes simplicity the default expectation.
Celebrate “boring wins” publicly. If team channels only shout out big, complex projects, people optimize for those. Consequently, recognize engineers who deleted code. Additionally, highlight the person who said “we don’t need this yet” and was right. Make pragmatism visible in the same way you currently make complexity visible.
Rewrite promotion criteria. Add explicit requirements: “Demonstrates sound judgment in choosing appropriate complexity level.” Value negative work: “What did you decide NOT to build? What problems did you avoid?” Measure outcomes—business impact, time-to-market, maintenance burden—not just architectural sophistication. In promotion discussions, push back on packets that list impressive-sounding systems without demonstrable business value.
This requires real change, not lip service. If you keep rewarding complexity and ignoring simplicity, don’t act surprised when that’s exactly what you get.
Key Takeaways
- Promotion systems measure “impact” by complexity and scope, creating incentives where engineers build unnecessary architectures to look promotable rather than shipping pragmatic solutions that deliver business value
- The problem cascades through careers: interviews reward demonstrating complex knowledge over judgment, design reviews default to “future-proofing,” and promotion committees can’t see business context behind simple solutions
- Engineers can fight back by documenting alternatives they rejected, quantifying trade-offs, and defining specific signals for when complexity becomes necessary—making pragmatic decisions visible to promotion committees
- Leaders must fix the structure: shift design review questions to make simplicity the default, celebrate engineers who delete code and reject unnecessary features, and rewrite promotion criteria to value judgment over architectural complexity
- This is a leadership failure, not an engineer problem—systems that reward complexity over business value need explicit structural changes, not individual workarounds
