Edsger Dijkstra once wrote: “Simplicity is a great virtue, but it requires hard work to achieve and education to appreciate. And to make matters worse, complexity sells better.” That was in 1984. Forty-two years later, we still haven’t figured it out.
I’ve been thinking about this a lot because I keep seeing the same pattern at companies I’ve worked at and in conversations with friends at other shops. The engineer who ships a boring solution gets a pat on the back. The engineer who builds something elaborate gets a promotion. Everyone kind of knows this is wrong, but nobody changes it.
How promotion packets actually work
Promotion committees at most tech companies evaluate “impact,” and impact is measured by what you built, how big it was, and how many people it affected. Google’s promotion process, which half the industry has copied in some form, explicitly looks for “increasing scope” as you move up levels. The Staff Engineer archetypes Will Larson describes all involve operating at larger and larger scales.
None of that is inherently bad. But it creates a gravitational pull toward building more, not less. A straightforward implementation that ships in two days and runs without incident for six months is genuinely hard to write a compelling promo case around. Meanwhile, the engineer who introduced an event-driven architecture with a custom configuration framework has a story that practically writes itself, even if the team didn’t need any of it.
Kent Beck put it well: “I’m not a great programmer; I’m just a good programmer with great habits.” One of those habits is resisting the urge to build the impressive thing when the boring thing works fine.
We train people to do this
The bias starts before anyone gets hired. In system design interviews, you propose a single Postgres database behind a REST API and the interviewer pushes: “What about 10 million users?” So you add Redis, then Kafka, then a sharded database with read replicas, and by the end you’ve drawn an architecture diagram for a system that 99% of companies will never need. The interviewer nods approvingly. Lesson learned: simple wasn’t enough.
To be fair, interviewers sometimes have good reasons to push on scale. They want to know if you understand distributed systems and can reason about tradeoffs under pressure. But the meta-lesson candidates absorb is that complexity impresses people. And that sticks.
Design reviews have the same problem. Someone proposes a clean approach and gets hit with “shouldn’t we future-proof this?” So they go back and add layers for problems that might never show up. I’ve done this myself. I once built an elaborate plugin system for a feature that ended up having exactly one plugin, ever. The abstraction cost more time to maintain than it would have taken to just copy-paste the 30 lines of code if we ever needed a second one.
Martin Fowler’s YAGNI principle (“You Aren’t Gonna Need It”) gets nodded at in every architecture discussion and ignored in most of them. The social pressure to look like you’ve thought of everything is stronger than the engineering principle telling you to wait until you actually need it.
Complexity has real costs people ignore
There’s a paper from 2022 by researchers at Microsoft, “The Space of Developer Productivity”, that found developer satisfaction and productivity are strongly correlated with codebase simplicity and low cognitive load. This lines up with what most of us already feel: working in an over-engineered codebase is exhausting. Every change requires understanding three layers of abstraction before you can touch anything.
Sandi Metz talks about this in terms of the wrong abstraction: “Prefer duplication over the wrong abstraction.” I’ve seen engineers create elaborate class hierarchies to avoid repeating 10 lines of code, then spend weeks debugging the hierarchy when requirements changed slightly. The duplication would have been fine. More than fine, actually. It would have been obvious and easy to change.
Google’s own internal studies on code health found that the highest-rated codebases weren’t the most cleverly architected. They were the ones where a new team member could make a change within their first week. Simplicity isn’t just an aesthetic preference, it directly affects how fast a team can move.
The actual path to seniority
The confidence to not build something is weirdly rare. Anyone can add complexity, it’s the default mode of engineering. Leaving it out means you’ve actually thought through the problem and made a deliberate choice. That’s harder than it looks.
The best senior engineers I’ve worked with don’t know more tools and patterns than everyone else. They know when not to use them. Their code makes you think “well, yeah, of course” because there’s nothing clever about it, nothing that makes you feel stupid. That clarity comes from experience, not from a lack of skill.
Rich Hickey’s talk “Simple Made Easy” draws a distinction worth remembering: simple means “not compound,” having one role or concept. Easy means “near at hand,” familiar. They’re not the same thing. A microservice architecture might be easy to reach for if that’s what you’ve always done, but it’s not simple for a problem that a monolith handles fine.
Making simplicity visible
Your work won’t speak for itself. Not because it’s not good, but because promotion systems aren’t built to hear it.
“Shipped feature X” doesn’t capture anything. But “evaluated three approaches including an event-driven model, determined the straightforward implementation met all current requirements, shipped in two days with zero incidents over six months” tells the real story. The decision not to build something is an architectural decision. Write it up like one.
When someone asks “shouldn’t we future-proof this?” in a review, don’t just cave. Try: “Here’s what it would cost to add that later, and here’s what it costs us to add it now. I think we wait.” You’re showing your work, not pushing back.
On the leadership side, the single best thing a tech lead can do is change the default question. Instead of “have we thought about scale?”, ask “what’s the simplest version we can ship, and what signals would tell us we need more?” That one swap puts the burden of proof on complexity instead of simplicity. And pay attention to what gets celebrated publicly. If every shout-out goes to the big complex project, that’s what people will optimize for. Start recognizing the engineer who deleted code, or the one who said “we don’t need this yet” and turned out to be right.
The uncomfortable part
Some teams genuinely value this. Others say they do but promote the opposite. If you do everything right and your organization still only rewards elaborate systems, that’s useful information. It tells you where you work. You can either play the game or find a place where good judgment is actually recognized.
But at least you’ll know which one you’re in.
This post was inspired by a piece on terriblesoftware.org on the same topic, which I recommend reading.