alt Hacker NewsThis 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.
Replies
In a functional org, the principal engineer's role would be to review designs to reduce complexity and new systems. The goal of the org (and engineers within the org by extension) is to deliver impact. The engineer who can ship the impact of 3 new features with simple implementations in the time that it takes one complex implementation to be build should be promoted.
some bits of LLMese in this comment, to my ears at least. Especially "That’s the kind of impact that compounds"
> 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.”
This has been my personal mission and motivation to go into management. I see my job as making sure engineers are rewarded for building the simplest thing that works.
So far the best way to align incentives that I've found is a simple policy: We'll ship whatever you want, but we know your phone number and you're on-call for your systems. At least 2nd tier on call.
It's a little mean but you'd be surprised how quickly engineers start simplifying stuff when they feel like they can't get anything done because someone's always asking questions or triggering alarms about that weird thing they built 3 months ago.
> 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
I do the system design interview. The easiest way to fail is to over-design the solution. I am going to ask deep probing questions and you better have answers. My favorite answer is when people go "Oh yeah you're right, this box doesn't add any value, we can remove".