Nobody Gets Promoted for Simplicity

Source: Hacker News

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

The Hidden Problem

I think there’s something quietly screwing up a lot of engineering teams. In interviews, promotion packets, and design reviews, the engineer who over‑builds gets a compelling narrative, while the engineer who ships the simplest thing that works gets… nothing.

This isn’t intentional, of course. Nobody sits down and says, “let’s make sure the people who over‑engineer things get promoted!” But that’s what can happen (and it has, over and over again) when companies evaluate work incorrectly.

Two Contrasting Engineers

Engineer A

• Assigned a feature.
• Looks at the problem, considers a few options, and picks the simplest solution.
• Writes a straightforward implementation (~50 lines).
• Easy to read, easy to test, easy for the next person to pick up.
• Ships it in a couple of days and moves on.

Engineer B

• Assigned a similar feature.
• Sees an opportunity to build something more “robust.”
• Introduces a new abstraction layer, a pub/sub system for component communication, and a configuration framework for future extensibility.
• Takes three weeks, involves multiple PRs, and generates a lot of excited emojis when he shares the accompanying design doc.

When promotion time arrives, Engineer B’s work practically writes itself into a promotion packet:

“Designed and implemented a scalable event‑driven architecture, introduced a reusable abstraction layer adopted by multiple teams, and built a configuration framework enabling future extensibility.”

That practically screams Staff+.

For Engineer A, the narrative is almost non‑existent:

“Implemented feature X.”

Three words. Her work was better, but it’s invisible because of how simple she made it look. Nobody gets promoted for the complexity they avoided.

Why Complexity Gets Rewarded

Complexity looks smart—not because it is, but because our systems are set up to reward it. The incentive problem doesn’t start at promotion time; it starts before you even get the job.

Interviews

In a system‑design round you propose a simple solution: a single database, a straightforward API, maybe a caching layer. The interviewer asks, “What about scalability? What if you have ten million users?” You add services, queues, sharding, and more boxes on the whiteboard. The interviewer finally seems satisfied.

The lesson you take away is that complexity impresses people. The simple answer wasn’t wrong; it just wasn’t interesting enough. (Interviewers sometimes have good reasons to push on scale, but when the takeaway for the candidate is “simple wasn’t enough,” something’s off.)

Design Reviews

An engineer proposes a clean, simple approach and gets hit with “shouldn’t we future‑proof this?” They go back and add layers they don’t need yet, abstractions for problems that might never materialize, flexibility for requirements nobody has 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 duplicating a few lines of code, only to end up with something far harder to understand and maintain than the duplication ever was. Every time it felt like the right thing to do. The code looked more “professional,” more engineered. But the users didn’t get their feature any faster, and the next engineer had to spend half a day understanding the abstraction before they could make any changes.

When Complexity Is Actually Right

Now, let me be clear: complexity is sometimes the right call.

• If you’re processing millions of transactions, you might need distributed systems.
• If you have ten teams working on the same product, you probably need service boundaries.

When the problem is complex, the solution (probably) should be too.

The issue isn’t complexity itself; it’s unearned complexity. There’s a difference between:

• “We’re hitting database limits and need to shard.”
• “We might hit database limits in three years, so let’s shard now.”

The Real Skill: Knowing When Not to Add Complexity

Some engineers understand this. When you look at their code (and architecture) you think, “well, yeah, of course.” There’s no magic, no cleverness, nothing that makes you feel stupid for not understanding it. And that’s exactly the point.

The actual path to seniority isn’t learning more tools and patterns; it’s learning when not to use them. Anyone can add complexity. It takes experience and confidence to leave it out.

What Can We Do About It?

Saying “keep it simple” is easy. Changing incentive structures is harder.

For Engineers

1. Make simplicity visible. The work doesn’t speak for itself, not because it’s not good, but because most systems aren’t designed to hear it.

2. Talk about your own work strategically.

   • Instead of: “Implemented feature X.”
   • Say: “Evaluated three approaches—including an event‑driven architecture and a custom abstraction layer—determined that a straightforward implementation met all current and projected requirements, and shipped in two days with zero incidents over six months.”

   The decision not to build something is a decision, an important one! Document it accordingly.

In Design Reviews

When someone asks, “Shouldn’t we future‑proof this?”, don’t automatically cave and add a layer. Respond with a concise justification:

“We evaluated future‑proofing options and concluded that the current scope does not justify additional abstraction. Adding it now would increase maintenance burden without measurable benefit.”

Closing Thought

Complexity is easy to showcase; simplicity is easy to overlook. By explicitly articulating the trade‑offs behind a simple solution, we can shift the narrative from “more is better” to “the right amount is better.” That, in turn, aligns promotions, interviews, and reviews with the true value engineers bring: delivering reliable, maintainable software with the minimal necessary complexity.

How to Advocate for Simplicity (and Get Recognized for It)

1. Frame the Decision with Data

“Here’s what it would take to add that later if we need it, and here’s what it costs us to add it now. I think we wait.”

• You’re not pushing back; you’re showing you’ve done your homework.
• You’ve considered the complexity and deliberately chosen not to take it on.

2. Bring It Up With Your Manager

“I want to make sure 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 frame that for my next review?”

• Most managers will appreciate this because you’re making their job easier.
• You’re giving them language they can use to advocate for you.

3. Interpret the Outcome

• If the team still promotes the person who builds the most elaborate system:

  • That’s useful information.
  • It tells you something about the culture you’re in.

• Two possible cultures:

  1. Values simplicity – good judgment is recognized.
  2. Claims to value simplicity but rewards complexity – you can either play the game or look for a place where good judgment is actually recognized.

• At least you’ll know which one you’re in.

If You’re an Engineering Leader

You set the incentives, whether you realize it or not. Most promotion criteria are designed—intentionally or not—to reward complexity. “Impact” is often measured by the size and scope of what someone built, even when the avoidance of unnecessary complexity should also matter.

A. Change the Questions You Ask

• Design reviews:

  • Instead of “Have we thought about scale?” 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 and puts the burden of proof on complexity.

B. Push Back in Promotion Discussions

• When a promotion packet is a list of impressive‑sounding systems, ask:

  “Was all of that necessary? Did we actually need a pub/sub system here, or did it just look good on paper?”

• When an engineer ships something clean and simple, help them write the narrative:

  “Evaluated multiple approaches and chose the simplest one that solved the problem.”

  This is a compelling promotion case—if you treat it like one.

C. Celebrate Simplicity Publicly

• If every shout‑out in your team channel is for a big, complex project, that’s what people will optimize for.
• Start recognizing:
  • The engineer who deleted dead code.
  • The person who said, “We don’t need this yet,” and was right.

Bottom Line

If we keep rewarding complexity and ignoring simplicity, we shouldn’t be surprised when that’s exactly what we get. The fix isn’t complicated—which, I guess, is kind of the point.