Nobody Gets Promoted for Simplicity

cyberax

I was promoted for getting rid of multiple services in favor of a small compact implementation. I also promote and advocate for people who push for simple solutions with as little infrastructure as possible.

danpalmer

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.

shevy-java

Simplicity is great but it is orthogonal to features. One could add many simple features and combine them e. g. the UNIX pipe philosophy, but it still adds a cognitive load. I failed to memorise awk, so I worked around it by simply using ruby as surrogate. And I still add "actionable-code" to do specific tasks, all in an attempt to avoid having to burden my weak brain with hard-to-memorize tokens and sigils. I kind of think in terms of the computer as a DSL wrapper, but with a more flexible syntax than the traditional bash/shell script syntax (or awk or perl or sed; I do actually use sed since it is so convenient but I am not the biggest fan of it either).

dfxm12

Selling your work is distinct from simplicity. Despite the headline, the article is mostly arguing that how well you promote your work is the most important metric when it comes to promotions. This jives with my personal experience & advice from managers.

scuff3d

"Identified and implemented a streamlined solution that delivered the required functionality in approximately 50 lines of code, prioritizing clarity, maintainability, and operational efficiency. Proactively evaluated alternative approaches and intentionally avoided unnecessary architectural complexity, reducing long-term maintenance overhead and accelerating delivery timelines. Demonstrated strong engineering judgment by aligning implementation scope with business needs while preserving flexibility for future iteration." This isn't an engineering problem, it's a sales problem. Also, you don't even have to be good at this stuff anymore. Any management nitwit would eat that up on a performance eval, and I had GPT write it for me. Prompt: "Write up the most corporate self eval possible for someone who identified a simple solution in only 50 lines of code, instead of creating an over architecture mess. Keep it to just three sentences"

rvz

Because unfortunately, someone proposing simplicity somehow means that it threatens another person's job security, which is quite frankly pathetic, even though it can lead to saving the business money and time. The only valid excuse is whether the risk is worth it vs the potential gains. But the solutions that I prefer are the ones that offer minimal changes with massive gains rather than co-ordinating with hundreds of teams for years over an unrelated change. If you have to do the latter for a tiny code change, then the architecture was most certainly built on a bad foundation, riddled with hundreds of brittle moving part waiting for an incident.

ChadMoran

I launched a technical feature on Amazon's retail platform that is responsible for 9 figures worth of revenue. When I launched it, it had no infrastructure. It was a collection of small changes across every core platform (Detail Page, Cart, Checkout, etc). At first people were like "Well, you didn't do much" but when they saw the value things changed drastically. It's a bit of marketing you have to do to help bring people along. Often perceived impact is correlated with complexity, sadly.

trigvi

Excellent article. It's even worse for people who can build and run small/medium products end-to-end (coding, infra, handling prospects and customers directly, being mindful of costs) and are made to report to engineering managers, who clearly understand only the coding part.

Duanemclemore

Great article. Where my mind goes as a counterpoint that proves the point is the famous Bill Atkinson lore about -2000 lines of code[0]. As a practicing architect (of buildings) I had a special fondness of working on minimalist projects. Buildings are a complex problem space. You typically can't design out unnecessary complexity entirely. So you have to work backward from goals (the finished condition) to infrastructure (the building structure) to figure out how to make the end product look like almost nothing (Mies's "beinahe nichts"). That's all to say that "complexity impresses" as the article says, but the discerning understand that simplicity can be even more impressive. It also puts me in the frame of mind of another famous one - Fred Brooks's "No Silver Bullet" [1] and the idea of essential vs. accidental complexity. Or as I like to think of it in a slightly more nuanced way - not necessarily "accidental" but at least "incidental." [0] https://www.folklore.org/Negative_2000_Lines_Of_Code.html [1] https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...

xiphias2

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.

OpenWaygate

I'm more and more realize this since work. People wrap their solution with BIG TITLE and fancy words, while many simple but practical solutions are underestimated or not taken seriously.

losalah

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.

litchinn

I think there are several reasons for this. Firstly, simple design places higher demands on developers than complex design. You need sufficient experience and a deep understanding of the business to create a design that is just right. Otherwise, after several iterations, your code is likely to become bloated—for example, a single file exceeding 2,000 lines or a function stretching over 500 lines. Secondly, I strongly agree with a statement I once read (though I can’t recall the exact source): "Good code isn’t written perfectly from the start—it’s shaped through continuous refactoring. You need to refactor it at the right time." However, most companies simply don’t allocate time for such refactoring, as new requirements keep pouring in. Under these constraints, it becomes clear that most companies tend to favor complex design as an engineering trade-off. We have a range of tools for complex design, such as SOLID principles, design patterns, and DDD. But there’s little guidance on simplifying design. I rarely see blogs discussing how developers should judge whether a design is over-engineered or what constitutes a just-right design. In such cases, having some design is better than having none at all—after all, many companies truly operate without any design, relying solely on copying existing solutions.

semiinfinitely

* in idiotic organizations. I've was promoted for producing a significantly simplified replacement for an existing system that was critical. it happened because the culture rewards engineering excellence.

kjgkjhfkjf

The article seems to conflate complexity and scalability, but there's a kernel of truth to its premise. The larger the tech company, the more maddening the processes tend to be. Maybe the next generation of AI-enabled companies will be smaller and less bureaucratic.

al_borland

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.

tabs_or_spaces

I think the advice is good but maybe the title could be improved. > But for Engineer A’s work, there’s almost nothing to say. “Implemented feature X.” Three words. To me, this is the main problem. Engineer A is unable to describe the impact of their work, how the work affected the business. Your manager isn't responsible for promoting your own work, you are. > 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+. Maybe it's just the narrow of the article, but if promotion only looks at complexity and not quality of delivery and impact on the business then this isn't a good engineering team to be in. There are many cases where simplicity is celebrated and recognized. It's up to the engineer to know what the impact of their work is, if they can't do that then that's on them.

polotics

Refreshingly non-slop write-up, nice! One angle is also... when you hear: "well yes you delivered on time and it works, but this is because it was an easy task" Run!