I’ve gotten promoted for simplicity several times. “Why are we jumping through hoops to make an Xbase file on a network share be accessible to multiple users updating data at the same time? Uh, can I introduce you to PostgreSQL?”

“Hear me out: what if instead of deploying a fleet of web servers to handle 10M identical GET requests per second, we put a handful of servers behind a few Varnish caches with a 1 second expiration?”

“Wait, this thing is spec’d to serve 3000 requests per day and an acceptable downtime of 20 hours per week? Kubernetes is cool, but why don’t we spin up a single VPS and run the whole stack on it?”

There’s a subtle art to talking dev teams down off a ledge, but sometimes the simple path is better in every way. Being able to spot those times is golden. And, of course, knowing when the simplest reasonable version is still quite complex and being willing to roll with it is equally important.

This hit a nerve because “simplicity” is one of those things you only notice when it’s missing, and most orgs don’t have a good way to reward “the thing that didn’t happen.”

I’ve watched this exact dynamic play out: one person ships the boring implementation, nothing breaks, everyone moves on. Another person ships the “platform” version, there are docs, diagrams, an internal talk… and now there’s a subsystem that needs to be explained to every new hire. Guess which one looks like “impact” on paper.

The part I think is under-discussed is that complexity has a carrying cost that rarely gets charged to the builder. The team pays it later: more surface area, more failure modes, more time spent reading before changing. In that sense, unearned complexity is like taking on leverage. Sometimes it’s the right move, but you should need a business case, not just enthusiasm.

What’s helped on teams I’ve liked: make “simplicity” legible by treating it as a decision record. In the PR/ADR, explicitly list the two “cooler” options you didn’t take and why, and write down the trigger conditions for upgrading later (“if p95 > X for Y days”, “if we add a second producer”, etc.). That turns “implemented feature X” into “made a deliberate tradeoff, reduced risk, and defined a clear escape hatch.” It also forces the room to argue with specifics rather than vibes like “future-proofing.”

Also +1 on the interview point. A lot of system design interviews are accidentally training people that the goal is to draw more boxes until the interviewer nods. The more senior move is usually: start simple, instrument, set thresholds, and only then add machinery. But that’s harder to “perform” in 45 minutes than rattling off Kafka and sharding.

If an org wants to fix the incentive, I think the question to ask in reviews isn’t “how big was the thing you built,” it’s “did you make the system easier to change next quarter.” That’s the kind of impact that compounds, and it’s usually correlated with simplicity.

This is just not true, people get promoted for delivering impact whether the solution is complex or simple.

The best engineer I know who can work with huge complex systems in a big company usually starts with a complex solution then after he understands what he wants to achieve thinks backwards and reimplements it in the fewest possible lines of code change with the already complex system.

I’ve also seen this show up with stable vs buggy code.

Person A writes some code that just works, no one hears about it and the developer may tend to fade into the background.

Person B made a lot of mistakes is always stepping in to fix problems and be the hero, and everyone forgets that they caused those issues in the first place.

When it comes time for promotions, Person B is fresh in everyone’s mind due to the heroics performed to fix their own code over the weekend. They can take credit for the features being shipped and the operational work done to help run it.

Meanwhile, Person A is overlooked, they just shipped some solid code and were able to get a good night sleep.

You definitely get promoted for simplicity, if it translates to the real world in a tangible way: When other people are hard to work with because their solutions bear all the hallmarks of being overly complicated or complex and cause problems more often, higher ups or peers might not always be close enough to the technicalities to understand why – but they are not daft and can notice patterns. Attribution will not be fair in every single instance, but it averages out.

People who are easy to work with get promoted, and that is downstream from building simple solutions.

In my experience this doesn't happen as often as some people like to state. It tends to be less experienced, more junior, engineers that propose complex solutions, and more experienced engineers are the ones driving simplicity – both because they've been burned by complexity and value the simplicity more, and because they have the experience to clarify and distil problems down enough to get to the simplest solutions.

I think it's easy to state this sort of opinion, it sounds good on the surface, but I don't feel it stands up to scrutiny. I'd like to see some evidence or studies done to see if this is actually a trend.

I think of this every time I see hundreds of interfaces, all with single class implementations.

The excuse always comes back "but it's extendable", how many implementations of a ConfigurationSingleton could you have in an application?

Put the class in and if you need the interface later any refactoring tool can easily create it when you have that second class (which 99% of the time will never happen).'

This is what worries me when people say AI is great for boilerplate, I worry this is the kind of boilerplate they'll be creating because they've put "must be well designed and extendable" in their AGENTS.md.

One correction about interviews: if the interviewee comes up with an overengineered solution without asking any questions, it's definitely a red flag.

In a good interview, the interviewee would ask clarifying questions; perhaps get told to build something simple that works; and then follow-up questions would expand towards bigger scale to test the breadth of knowledge and experience of the candidate.

The thing being evaluated is not blindly repeating random "best practices", but understanding and adapting to requirements.

My company rewards impact because we work in a competitive industry and we feel like we cannot afford to waste time on unnecessary complexity. Our goal is to make money and if it doesn't meet business goals we don't waste time on it.

> Now, promotion time comes around. 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+.

What are these companies where you have unlimited money to pay engineers to solve problems in less efficient ways??

This is interesting because I specifically look for the opposite in interviews and design reviews. Yes, sometimes complexity is needed to handle scaling, extensibility, observability, security, and privacy, but most of the time it doesn't. I have new engineers who jump to designing big complicated modular systems with multiple levels of abstraction and I have to tell them to slow down and try something simpler. YAGNI is a real consideration.

My principal is: you don't have to do it right now, but make sure you could do it if you need to. This mainly comes down to avoiding assumptions. Simplifying assumptions can make things easier, but designs that don't leave room for extension make it really difficult to add those things later. It's a difficult balancing act, but I greatly appreciate any engineer who recognizes it and can manage it.