Nobody Gets Promoted for Simple Solutions

"Simplicity is a great virtue, but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells much better." — Edsger Dijkstra

In my view, many development teams share a common problem. Whether in interviews, promotion applications, or design reviews, the most impressive person is the one who built something extremely complex. If you developed a dead-simple working solution, it's unlikely to be appreciated.

Naturally, this isn't intentional. Nobody hatches a sinister plan like "Let's make sure only people who overcomplicate things get promoted." But it happens often when a company misjudges the work its employees do.

Let's imagine two developers on the same team — Alice and Bob. Alice is assigned to implement a feature. She analyzes several possible solutions and picks the simplest one — just 50 lines of code. It's easy to read, easy to test, and other developers will have no trouble understanding it in the future. Within two days, Alice implements the feature, tests it, ships it to production, and moves on to other tasks.

Bob gets a similar task. He evaluates it too, but sees a "more robust" approach. He adds an extra abstraction layer, creates a pub-sub system for inter-component communication, and adds a configuration structure so the feature can be "extended" in the future. It takes three weeks and several pull requests, and when he shares a design doc in the team chat, colleagues react with enthusiastic emoji.

Some time passes and promotion season arrives. Bob's work already sounds impressive: "Designed and implemented a scalable event-driven architecture, added a reusable abstraction layer adopted by multiple teams, and created a configuration framework for future feature extension." It practically screams senior-level.

Alice's work, on the other hand, doesn't have much to say. "Implemented feature X." Three words. Even though her work was better. But in the light of minimalism and simplicity, it's hard to notice. You can't write a compelling description of something you didn't build. That's why nobody gets promoted for avoiding unnecessary complexity.

Take interviews, for example. Imagine you're in a system design round and you propose a simple solution. One database, a straightforward API, and maybe a caching layer. The interviewer asks: "What about scalability? What if you have ten million users?" So you start drawing more boxes on the whiteboard — adding services, queues, and database sharding. Now the interviewer is happy.

All this tells us is that complexity impresses people. Your simple answer wasn't wrong. It just wasn't interesting enough. And you might start building on that conclusion throughout your career. To be fair, interviewers sometimes have good reasons to push on scale. They want to see how you reason under pressure and whether you understand distributed systems. But when the candidate takes away that "simple wasn't enough," that's a problem.

We see the same picture in design reviews. A developer proposes a clean, simple approach and hears: "Shouldn't we future-proof this?" So they start adding layers that aren't needed yet, abstractions for problems that may never arise, and flexibility for requirements nobody has stated. The reason isn't the requirements — it's the reviewers' expectations.

I've seen developers create abstractions just to avoid repeating a few lines of code, ultimately making the code much harder to understand. I've done it myself. Every time it feels like the right move. The code looks more "professional," more thoughtful. But it doesn't get users the feature any faster, and the next developer who encounters this code will spend half a day untangling the abstraction before they can make a single change.

To be clear, sometimes complex solutions are justified. If you're processing millions of transactions, you really might need distributed systems. If you have 10 teams working on a product, you'll probably need to establish service boundaries. When the problem itself is complex, the solution sometimes needs to be too.

The issue isn't complexity itself — it's unjustified complexity. There's a difference between "We're hitting the database limit — we need to shard" and "We might hit the database limit in three years, so let's shard now."

Some developers get this. And when you see their code (and architecture), you think, "Well, yeah, obviously." There's no magic, no showing off, nothing that makes you feel stupid for not understanding it. That's the point.

To truly become a senior developer, you need to do more than just learn additional tools and patterns — you need to understand when they're inappropriate. Anyone can pile on complexity. Avoiding it takes experience and confidence.

But what do we actually do about it? Saying "don't overcomplicate" is one thing. Changing the incentive system is another.

If You're a Developer

Remember: simplicity must be made visible. Work doesn't speak for itself. It's not that it isn't good enough — it's that most reward systems can't "hear" it.

Start with how you present it. "Implemented feature X" says very little. But "Evaluated three solutions including an event-driven architecture and a custom abstraction layer. Determined that a straightforward implementation meets all current and projected requirements. Delivered the solution in two days with zero incidents over six months" — that's the same simple work, but now with the reasoning behind it. The decision not to build something is also a decision, and an important one. So describe it accordingly.

When someone asks you in a design review, "Shouldn't we think about the future?" — don't cave in and start adding layers. Lay out your thinking: "Here's what it would take to add this later if needed. Here's what it costs to add it now. I think we should wait." You're not refusing — you're showing that you've thought it through. You considered the complexity and decided against it.

And make sure to bring this up with your manager. Something like: "I want my work description to reflect not just the code, but the decisions I made. Let's figure out how to frame this for my next review." Most managers will appreciate this approach because you're making their job easier by offering language that helps them argue your case.

Now, let's say you do all of this, but your team still promotes whoever builds the most convoluted systems. That tells you something useful about where you work. Some cultures genuinely value simplicity. Some only claim to, but reward the opposite. If you find yourself in the second type, you can either play by its rules or look for a place that recognizes and values sound reasoning. But at least you'll know where you stand.

If You're a Manager

In that case, you bear more responsibility. You set the foundation for the incentive system, whether consciously or not. And the problem is that most evaluation criteria are geared toward rewarding complexity, even if that wasn't the intent. Value is determined by the size and scope of the feature delivered. But those metrics often don't matter much. And it's also important to consider what the author avoided in their implementation.

Try to reframe the question. In design reviews, instead of "Have we accounted for scalability?" ask: "What does the simplest version of this feature look like, and what signals would tell us we need something more complex?" That single question changes the game by putting simplicity front and center and requiring justification for complexity — not the other way around.

When discussing promotions, push back on applications that simply list impressive-sounding systems. Ask: "Was all of this necessary? Did we really need a pub-sub system here, or does it just look good on paper?" And when a developer on your team ships something simple and clean, help them describe their work as: "Evaluated multiple approaches and chose the simplest one that fully solved the problem." That description will sound compelling in a promotion context — but only if you genuinely believe it.

One more thing — pay attention to what you celebrate in public conversations. If every mention in your team's chat is about a big, complex project, that's what everyone will optimize for. Start praising people who deleted unnecessary code. People who said "we don't need this yet" and turned out to be right.

Ultimately, if we keep rewarding complexity and ignoring simplicity, we shouldn't be surprised when complexity is what we get. But fixing this isn't hard. Which is, of course, the whole point.