“Simplicity is a noble virtue, but it requires hard work to acquire and an education to appreciate. And to make matters worse, complexity sells better.” -Edsger Dijkstra
I think there is something quietly wrong with a lot of engineering teams. In interviews, in promotional packets, in design reviews: The engineer who overbuilds gets a compelling narrative, but the one who does the simplest work gets nothing… nothing.
Of course, this is not intentional. No one sits and says, “Let’s make sure people who over-engineer things get promoted!” But this can happen (and has happened repeatedly) when companies misevaluate the work.
Imagine two engineers on the same team. Engineer A is assigned to a facility. She looks at the problem, considers a few options and chooses the simplest one. A straightforward implementation, maybe 50 lines of code. Easy to read, easy to test, easy for the next person to understand. It works. She sends it in a few days and moves on.
Engineer B gets a similar facility. He sees the problem too, but he sees an opportunity to build something even more “strong”. He introduces a new abstraction layer, creates a pub/sub system for communication between components, adds a configuration framework so that the feature is “extensible” for future use cases. It takes three weeks. There are many PRs. There were lots of excited emojis when he shared the document explaining all this.
Now, it’s time for promotion. Engineer B’s job practically writes itself into the promotion packet: “Designed and implemented a scalable event-driven architecture, introduced a reusable abstraction layer adopted by multiple teams, and created a configuration framework to enable future extensibility.” That practically screams Staff+.
But there is almost nothing to say about the work of Engineer A. “Implemented feature X.” three words. His work was better. But it’s invisible because he’s made it so simple. You can’t write an interesting story about something that’s about was not Construction No one gets a promotion for the complexity they avoided.
Complexity looks smart. Not because it is, but because our systems are set up to reward it. And incentive problems don’t start at the time of promotion. This starts even before you get the job.
Think about the interview. You are in the system design phase, and you propose a simple solution. A single database, a straightforward API, maybe a caching layer. The interviewer is as follows: “What about scalability? What if you have ten million users?” So you add services. You add rows. You add sharding. You draw more boxes on the whiteboard. The interviewer finally seems satisfied now.
You just learned that complexity impresses people. The simple answer was not wrong. It wasn’t that interesting. And you can take that lesson with you into your career. To be fair, interviewers sometimes have good reasons for being massively forward; They want to see how you think under pressure and whether you understand distributed systems. But when it’s said to a candidate that “simplicity wasn’t enough,” something goes wrong.
This is also reflected in design reviews. An engineer proposes a neat, simple way and gets a shock “Shouldn’t we future proof it?” So they go back and add layers they don’t need yet, abstractions for problems that will probably never be met, flexibilities for requirements that no one asked for. Not because the problem demanded it, but because the room expected it.
I’ve seen engineers (and have been one myself) create abstractions to avoid copying a few lines of code, but that ends up being something more difficult to understand and maintain than the copy. Every time, it felt like the right thing to do. The code looked more “professional”. More engineers. But users didn’t find their feature fast enough, and the next engineer who touched it had to spend half a day understanding the abstraction before making any changes.
Now, let me be clear: complexity is sometimes the right decision. If you are processing millions of transactions, you may need a distributed system. If you have 10 teams working on the same product, you’ll probably need service limits. When the problem is complex, the solution (probably) should be too!
The matter is not just about complexity. This is unearned complexity. There is a difference between “We are exceeding database limits and need to fix” And “We may reach the database limit in three years, so let’s get right now.”
Some engineers understand this. And when you look at their code (and architecture), you think “Okay, yes, of course.” There’s no magic to it, no cleverness, nothing that makes you feel stupid for not understanding it. And that’s exactly the point.
The real path to seniority is not to learn more tools and patterns, but to learn when not to use them. Anyone can add complexity. It takes experience and confidence to quit.
So what do we actually do about it? Because “keep it simple” is easier said than done. Incentive structures are hard to change.
if you are an engineerLearn that simplicity needs to be made visible. The work does not speak for itself; Not because it’s not good, but because most systems aren’t designed to hear it.
Start with how you talk about your work. “Implemented feature X” doesn’t mean much. But “Evaluated three approaches, including an event-driven architecture and a custom abstraction layer, determined that a straightforward implementation met all existing and anticipated requirements, and shipped in two days with zero incidents in six months”It’s the same simple task, just described in a way that captures the decision behind it. Decision No Making something is a decision, an important decision! Document it accordingly.
In design reviews, when someone asks “shouldn’t we future proof this?”, don’t just shut up and try to add layers. try: “Here’s what it would take to add it if we need it later, and what it would cost us to add it now. I guess we wait.” You are not holding back, but rather showing that you have done your homework. You considered the complexity and decided not to take it.
And yes, bring it up to your manager. Something like this: “I want to make sure that the way I document my work reflects the decisions I’m making, not just the code I’m writing. Can we talk about how to prepare it for our next review?” Most managers will appreciate this because you are making their job easier. You are giving them language they can use to advocate for you.
Now, if you do all this and your team still only promotes the person who builds the most detailed system… that’s also useful information. It tells you something about where you work. Some cultures really value simplicity. Others say they do, but reward the opposite. If you’re in the second type, you can either play the game or find a place where good judgment is actually recognized. But at least you’ll know what you’re in for.
If you are an engineering leaderIt’s on you more than anyone else. You set the incentives, whether you realize it or not. And the problem is that most promotion criteria are fundamentally designed to reward complexity, even if that’s not their intention. “Impact” is measured by the size and scope of what one has created, which often doesn’t matter! But what he avoided should also matter.
So start by changing the questions you ask. In design reviews, “Have we thought about scale?” Instead of, try “What’s the simplest version we can send, and what specific signals will tell us we need something more complex?” That one question changes the game: it makes simplicity the default and puts the burden of proof on complexity, not the other way around!
In promotion discussions, push back when someone’s packet is basically a list of impressive-sounding systems. Ask: “Was it all necessary? Did we really need a pub/sub system here, or did it just look good on paper?” And when an engineer on your team sends something clean and simple, help him write the narrative. “Multiple approaches were evaluated and the simplest approach that solved the problem was chosen” Is A compelling promotion case, but only if you really treat it like one.
One more thing: Pay attention to what you celebrate in public. If every shoutout in your team channel is for a big, complex project, people will adapt to that. Start by identifying the engineer who deleted the code. Who said “we don’t need it right now” and he was right.
At the end of the day, if we keep rewarding complexity and ignoring simplicity, we shouldn’t be surprised when that’s exactly what we get. But the solution is not complicated. Which, I guess, is kind of the point.
<a href