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.
> 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".
But that's an unpopular approach these days where many companies are obsessed with minimising the bus factor to the point that their IP is as replaceable as their employees.
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.
sorry it came off that way. I dictated that one in Obsidian, so it picked a slightly polished phrasing. What I meant is just: simple choices keep saving you time later.
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.
I've been person B and got promoted to staff engineer once.
I'm back to being a senior in a new org and I try to be person A, but be extra communicative of what I'm working on and how it impacts and why it's important.
I find I spend more time trying to understand how to explain the value my work has to the business (screenshots, demos, docs) than trying to actually do my work. But I think it's important though, otherwise I'll be the person A who never gets promoted.
> I find I spend more time trying to understand how to explain the value my work has to the business (screenshots, demos, docs) than trying to actually do my work.
I relate to this a lot. I was a product owner for a while and made sure we could always explain the value of what was being delivered to stakeholders in language they would understand and matter to them. We spent a lot of time on preparing the demo, running it through internally, providing feedback, tweaking the wording, gathering metrics, etc. In many cases the developer was really interested in the technicality of a certain function, but we’d push them to shift focus to the value that was being delivered to the people we were presenting to. The last thing we want is for people to tune out, because someone is deep diving into code no one understands or really cares about seeing.
In my view, it doesn’t matter what you do if no one understands what you did or why it matters. If we can tell the story well, we will be valued. As a result, the team got great feedback, was highly valued, and our management felt we were miles ahead of every other team.
Fast-forward to now… I chose to move back to an engineering role. We don’t do demos anymore, despite protests from the team. No one knows what we do. We’ve seen multiple people laid off from the team and our direction is all over the place. It feels like we can never catch up, which is a far cry from the days when my boss was telling me to take a 3 month vacation, because of how far ahead we were.
This small shift in focus and opinions around things like demos has dramatically changed the team, how the work is viewed, and the team’s morale. It’s been very upsetting.
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.
There's exception and geniuses to every rule. In general however a simple solution will be much more difficult to argue a promotion around even if you make a ton of impact. You may get a top rating and a slightly larger bonus however not a promotion.
Every large company has a ladder for promotions that includes many words that basically come down to "complex." "Drive a year long initiative" or "multiple teams" or "large complex task with multiple components" are all examples I've seen.
I’m here to support both of your statements. This is absolutely true from orgs the size of FAANG to startups because I’ve worked at both. Sure smooth talkers get promoted but so do smart people who make things work better by simplifying.
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 boiler plate, I worry this is the kind of boiler plate they'll be creating.
I haven't seen AI systems do this in my experience unless you specifically ask for it. Sometimes the outcomes can be a bit complex, but I find myself having to prompt it specifically when I want something more abstract.
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.
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 haven't worked at that many companies to have an informed opinion, but I've certainly been at a couple of places where smart people went along with ridiculous complexity, but part of the reason was there was already a hugely complicated mess with way too many people working on it for a simple solution to be politically feasible.
While the post seems simple, it's arguably complex, as the comments here point out.
Simple solutions are good enough some of the time, perhaps even most of the time, but often fall down with edge cases. But edge cases add up, and dealing with them is complicated.
For example, calculating pay for hourly paid workers is a "simple" problem. Deduct start time from end time and multiply by rate. Covers 90% of the workforce.
But the other 10% take much more work. That team that rotates an on-call worker (which earms an allowance), who gets a call (first hour is free, next is double time etc.)
So it is with software. Adding 2 numbers is trivial. But what about overflows? What about underflows? What if one number is infinity? What if it's i?
The simple solution is "just add, ignore edge cases". The complex solution handles the edge cases. Which is better in the long run?
I think it's important to understand the domain to know if those edge cases are likely to happen. If no one on payroll is ever on call, then no need to design for that. Solution works as intended. If it turns out we need a more robust calculator later, then we can design for that. But adding that complexity before the domain requires it seems unnecessary to me.
But also, just because there is complexity in the domain doesn't mean there needs to be complexity in the software. An elegant, simple solution could be implemented for calculating payroll or adding infinity. That's the hard part though.
This is true, I think there's also quite a lot of folks sticking their head in the sand about complexity. Software should be as simple as possible _but no simpler_, yet I see a lot of people floating "simple" solutions that don't actually meet the requirements. By all means be skeptical of requirements, but disregarding them without any work to remove them, is just bad engineering.
The engineering team at a large bank some time ago did a blog post of having over 4,000+ microservices where a single API call from the client interacts with 1,100 of those microservices. Sounds great a great architechture right? /s
Would you want to be in charge of simplifing this architecture for a 'senior staff' title for 4+ years?
This is just one of many examples who have this sort of complexity and it is celebrated, and the microservices hype (originated from Netflix and overhyped by Thoughtworks) have somewhat caused this madness and for some, it has turned into a mountain of technical debt to maintain.
Unless you have a very good reason to save a company from drowing over it's own complex infrastructure costs to run itself, attempting to simplify this architecture will be met with feroucious backlash by other teams of senior staff engineers, hundreds of meetings with risk officers and being blocked because of forever meetings with architects.
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.
> 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.
… the impact of my work is more often than not opaque to me, the person doing the work. More often than not I'm not the one setting the priorities, and way more often than not the real world impacts like "we brought in $X M with that feature you wrote" is quite simply not visible to me because "that's not what engineers do".
I would love to know these things, I'd love to have that level of visibility, but finance at tech companies is nearly always a black box. Best I get as an engineer is that I know how much cloud compute costs, so I can figure out the expense side of stuff.
If anything, I usually have to go for far more intangibles: "this internal manager was happy", "this adjacent team had all their wishes and desires fulfilled", etc.
Otherwise, stuff feels like it plays out like the bits you quoted from TFA.
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."
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.
Coincidentally similar story, but with a different end -- I eliminated a test station from the final assembly line for Astro (Amazon's home robot), because there were no unique failure modes that the test station could catch (we collected ideas, and then went through and analyzed every failure mode suggested, they would all be detected by other stations). I think we estimated that was ~$1 million savings, in addition to simplifying the workflow and reducing time spent to do final testing. I brought this up with my manager when pushing for a promo, but he told me "somebody else made that value, you just stopped it from being thrown away", lol. Maybe I should have pushed harder, but I definitely felt underappreciated, and am still not sure if I could have gotten better recognition for it.
Don't feel sorry for me though, they still paid me well enough, and I'm happily doing my own stuff now :)
How do you ascribe a revenue number like that based on one collection of changes in a huge system? Presumably there were a bunch of other features being released around the same time as it. Was there a lot of A/B testing around it?
"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"
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.
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).
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.
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.
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.
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.
As a /former/ EM at an almost-household-name-tech-company, I can explain.
First of all, unless you're at a tiny startup (where quality of engineering isn't even on the horizon), you don't really get promoted by your manager. You get promoted by your manager's manager. Your manager simply "proposes" your promotion, almost as an idea.
Obviously your EM doesn't wanna propose ideas that will be indefensible, so the decision to propose you is a function of roughly four variables:
0. How consistently you've shipped stuff. It can be the most complex, terrible, haphazardly put together piece of shit, implemented in 6000-line functions, but if it ships when you said it would ship, and the feature works on launch -- really works, without causing incidents and headaches over the next two weeks, you're golden
1. How much effort you made in terms of energy exertion. This is usually counted in hours of work. You're a lot more likely to get promoted if you spend 16 hours at the office, even if 15 of those are just watching mountain bike review videos in a small tab opened on the side, with your noise-canceling headphones on
2. How much enthusiasm / good intent / positivity you exert. Engineers who are "excited" about the company and the privilege of having a job in it and are demonstrating creative thinking in the interest of "changing the world" (read: "increasing shareholder value") are more likely to get proposed for promotion than those who know better
3. How much everyone around you likes you. The proverbial "soft skills". If everyone around you says "that person is incredible, I love working with that person, they're so smart / hard-working / nice / pleasant", both in public and in private, you're much easier to promote
With rare exceptions, your direct manager probably understands pretty well who's actually doing what, how, when, and how much, in terms of substance and not fluff. But their manager is too far removed from it all. Their manager, in fact, likely wants to make sure there's no favoritism or anything funky going on, so when your manager proposes you for promotion, their manager wants to see objectively measurable stats, proving that you deserve the promotion.
It's really difficult (read: impossible) for your manager's manager to tell an easy project from a challenging project made easy by you being so competent. Your manager's manager wants a war story, with dramatic character development, and an unlikely victory by the protagonist, against all the odds. Yes, during public Q&As they will say that they prefer you work smart, not hard. That it is foolish to measure programmer productivity by lines of code written or number of hours spent with noise-canceling headphones on at the office premises. What they won't mention is that they simply have no other way of measuring programmer productivity. Go ahead, ask them during the next all-hands. You'll get nothing of substance. "Here at ACME, we trust your manager", they will say.
So.
When your manager walks into that 1:1 with their boss, their boss wants to hear that you have, single-handedly, written gigalines of code, 16 hours a day, clicked <3 on every CTO message in the Engineering channel on Slack, and managed to do so without making everyone else in the company hate you.
Nobody who controls your promotion ever actually reads your code, or understands your solutions. Nobody ever loads up your architecture diagram or your implementation when discussing your promotion. Something to keep in mind. People in a position to give out "career rewards" are too busy, distracted, and uninvested in you personally to pay attention to anything other than quick, easily observable and defensible impressions.
I went to town on this in a blog a few years back "The Common Sense Guide to Not fucking up Your Business or Organization." <https://rodyne.com/?p=2024> as the action described in the original article is usually one of the first clues that something is wrong. I've seen many a good person leave companies and IT budgets subsequently balloon out of control with a completely laissez-faire attitude by senior management. I wish more CEO's would pick up on this stupidity.
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.
It sounds like they had a previously complex (and I assume problematic) system to compare it to. When complexity is causing problems and the job is to simplify to get rid of problems, it will be rewarded.
If it was made simple from the start, it would have likely been seen as an easy and solved problem, and you never would have been brought in, as no one would ever think about it again.
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.
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.
> 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".
Yup, in a word, ownership.
But that's an unpopular approach these days where many companies are obsessed with minimising the bus factor to the point that their IP is as replaceable as their employees.
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.
yes, I’m with you. Keep it simple, ship the thing, and only add a new system when you actually need it.
some bits of LLMese in this comment, to my ears at least. Especially "That’s the kind of impact that compounds"
sorry it came off that way. I dictated that one in Obsidian, so it picked a slightly polished phrasing. What I meant is just: simple choices keep saving you time later.
Well, people shouldn’t start writing word salad just because LLMs were trained on structured text.
Yeah, it kind of sounds like it to me also, but the idea “did you make the system easier to change next quarter” is a great way to measure progress.
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.
I've been person B and got promoted to staff engineer once.
I'm back to being a senior in a new org and I try to be person A, but be extra communicative of what I'm working on and how it impacts and why it's important.
I find I spend more time trying to understand how to explain the value my work has to the business (screenshots, demos, docs) than trying to actually do my work. But I think it's important though, otherwise I'll be the person A who never gets promoted.
> I find I spend more time trying to understand how to explain the value my work has to the business (screenshots, demos, docs) than trying to actually do my work.
I relate to this a lot. I was a product owner for a while and made sure we could always explain the value of what was being delivered to stakeholders in language they would understand and matter to them. We spent a lot of time on preparing the demo, running it through internally, providing feedback, tweaking the wording, gathering metrics, etc. In many cases the developer was really interested in the technicality of a certain function, but we’d push them to shift focus to the value that was being delivered to the people we were presenting to. The last thing we want is for people to tune out, because someone is deep diving into code no one understands or really cares about seeing.
In my view, it doesn’t matter what you do if no one understands what you did or why it matters. If we can tell the story well, we will be valued. As a result, the team got great feedback, was highly valued, and our management felt we were miles ahead of every other team.
Fast-forward to now… I chose to move back to an engineering role. We don’t do demos anymore, despite protests from the team. No one knows what we do. We’ve seen multiple people laid off from the team and our direction is all over the place. It feels like we can never catch up, which is a far cry from the days when my boss was telling me to take a 3 month vacation, because of how far ahead we were.
This small shift in focus and opinions around things like demos has dramatically changed the team, how the work is viewed, and the team’s morale. It’s been very upsetting.
The “Firefighter Becomes Arsonist” Organizational Anti-Pattern
Yes at least we can sleep.
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.
There's exception and geniuses to every rule. In general however a simple solution will be much more difficult to argue a promotion around even if you make a ton of impact. You may get a top rating and a slightly larger bonus however not a promotion.
Every large company has a ladder for promotions that includes many words that basically come down to "complex." "Drive a year long initiative" or "multiple teams" or "large complex task with multiple components" are all examples I've seen.
Was going to say something like this. If you're good at keeping things simple, it will help you deliver impact which can get you promoted.
I’m here to support both of your statements. This is absolutely true from orgs the size of FAANG to startups because I’ve worked at both. Sure smooth talkers get promoted but so do smart people who make things work better by simplifying.
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 boiler plate, I worry this is the kind of boiler plate they'll be creating.
I haven't seen AI systems do this in my experience unless you specifically ask for it. Sometimes the outcomes can be a bit complex, but I find myself having to prompt it specifically when I want something more abstract.
Honestly curious question: why do you think an interface adds complexity?
An interface specifies a contract that its users can depend on. Having one saves me from reading implementations of dependencies when reading a class.
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.
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 haven't worked at that many companies to have an informed opinion, but I've certainly been at a couple of places where smart people went along with ridiculous complexity, but part of the reason was there was already a hugely complicated mess with way too many people working on it for a simple solution to be politically feasible.
While the post seems simple, it's arguably complex, as the comments here point out.
Simple solutions are good enough some of the time, perhaps even most of the time, but often fall down with edge cases. But edge cases add up, and dealing with them is complicated.
For example, calculating pay for hourly paid workers is a "simple" problem. Deduct start time from end time and multiply by rate. Covers 90% of the workforce.
But the other 10% take much more work. That team that rotates an on-call worker (which earms an allowance), who gets a call (first hour is free, next is double time etc.)
So it is with software. Adding 2 numbers is trivial. But what about overflows? What about underflows? What if one number is infinity? What if it's i?
The simple solution is "just add, ignore edge cases". The complex solution handles the edge cases. Which is better in the long run?
Essential complexity is a class full of methods to compute your complicated payroll.
Unnecessary complexity is a microservice architecture to do the same thing.
I think it's important to understand the domain to know if those edge cases are likely to happen. If no one on payroll is ever on call, then no need to design for that. Solution works as intended. If it turns out we need a more robust calculator later, then we can design for that. But adding that complexity before the domain requires it seems unnecessary to me.
But also, just because there is complexity in the domain doesn't mean there needs to be complexity in the software. An elegant, simple solution could be implemented for calculating payroll or adding infinity. That's the hard part though.
This is true, I think there's also quite a lot of folks sticking their head in the sand about complexity. Software should be as simple as possible _but no simpler_, yet I see a lot of people floating "simple" solutions that don't actually meet the requirements. By all means be skeptical of requirements, but disregarding them without any work to remove them, is just bad engineering.
The engineering team at a large bank some time ago did a blog post of having over 4,000+ microservices where a single API call from the client interacts with 1,100 of those microservices. Sounds great a great architechture right? /s
Would you want to be in charge of simplifing this architecture for a 'senior staff' title for 4+ years?
This is just one of many examples who have this sort of complexity and it is celebrated, and the microservices hype (originated from Netflix and overhyped by Thoughtworks) have somewhat caused this madness and for some, it has turned into a mountain of technical debt to maintain.
Unless you have a very good reason to save a company from drowing over it's own complex infrastructure costs to run itself, attempting to simplify this architecture will be met with feroucious backlash by other teams of senior staff engineers, hundreds of meetings with risk officers and being blocked because of forever meetings with architects.
Software Complexity Vs Experience, diagram:
https://www.awesomesoftwareengineer.com/assets/resources/arc...
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.
> 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.
… the impact of my work is more often than not opaque to me, the person doing the work. More often than not I'm not the one setting the priorities, and way more often than not the real world impacts like "we brought in $X M with that feature you wrote" is quite simply not visible to me because "that's not what engineers do".
I would love to know these things, I'd love to have that level of visibility, but finance at tech companies is nearly always a black box. Best I get as an engineer is that I know how much cloud compute costs, so I can figure out the expense side of stuff.
If anything, I usually have to go for far more intangibles: "this internal manager was happy", "this adjacent team had all their wishes and desires fulfilled", etc.
Otherwise, stuff feels like it plays out like the bits you quoted from TFA.
This text is so true and should be a must read for every manager. I liked the text very much and can only recomend
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...
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.
Coincidentally similar story, but with a different end -- I eliminated a test station from the final assembly line for Astro (Amazon's home robot), because there were no unique failure modes that the test station could catch (we collected ideas, and then went through and analyzed every failure mode suggested, they would all be detected by other stations). I think we estimated that was ~$1 million savings, in addition to simplifying the workflow and reducing time spent to do final testing. I brought this up with my manager when pushing for a promo, but he told me "somebody else made that value, you just stopped it from being thrown away", lol. Maybe I should have pushed harder, but I definitely felt underappreciated, and am still not sure if I could have gotten better recognition for it.
Don't feel sorry for me though, they still paid me well enough, and I'm happily doing my own stuff now :)
How do you ascribe a revenue number like that based on one collection of changes in a huge system? Presumably there were a bunch of other features being released around the same time as it. Was there a lot of A/B testing around it?
Doesn’t matter, @ChadMoran is already on the fast track whilst you are on a pip.
"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"
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.
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).
This article is AI written meaning someone prompted chatgpt to write an article and then pasted the output here
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.
Oh, the bad guy is a he, and the good guy is a she, and no one bats an eye!
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.
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.
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.
As a /former/ EM at an almost-household-name-tech-company, I can explain.
First of all, unless you're at a tiny startup (where quality of engineering isn't even on the horizon), you don't really get promoted by your manager. You get promoted by your manager's manager. Your manager simply "proposes" your promotion, almost as an idea.
Obviously your EM doesn't wanna propose ideas that will be indefensible, so the decision to propose you is a function of roughly four variables:
0. How consistently you've shipped stuff. It can be the most complex, terrible, haphazardly put together piece of shit, implemented in 6000-line functions, but if it ships when you said it would ship, and the feature works on launch -- really works, without causing incidents and headaches over the next two weeks, you're golden
1. How much effort you made in terms of energy exertion. This is usually counted in hours of work. You're a lot more likely to get promoted if you spend 16 hours at the office, even if 15 of those are just watching mountain bike review videos in a small tab opened on the side, with your noise-canceling headphones on
2. How much enthusiasm / good intent / positivity you exert. Engineers who are "excited" about the company and the privilege of having a job in it and are demonstrating creative thinking in the interest of "changing the world" (read: "increasing shareholder value") are more likely to get proposed for promotion than those who know better
3. How much everyone around you likes you. The proverbial "soft skills". If everyone around you says "that person is incredible, I love working with that person, they're so smart / hard-working / nice / pleasant", both in public and in private, you're much easier to promote
With rare exceptions, your direct manager probably understands pretty well who's actually doing what, how, when, and how much, in terms of substance and not fluff. But their manager is too far removed from it all. Their manager, in fact, likely wants to make sure there's no favoritism or anything funky going on, so when your manager proposes you for promotion, their manager wants to see objectively measurable stats, proving that you deserve the promotion.
It's really difficult (read: impossible) for your manager's manager to tell an easy project from a challenging project made easy by you being so competent. Your manager's manager wants a war story, with dramatic character development, and an unlikely victory by the protagonist, against all the odds. Yes, during public Q&As they will say that they prefer you work smart, not hard. That it is foolish to measure programmer productivity by lines of code written or number of hours spent with noise-canceling headphones on at the office premises. What they won't mention is that they simply have no other way of measuring programmer productivity. Go ahead, ask them during the next all-hands. You'll get nothing of substance. "Here at ACME, we trust your manager", they will say.
So.
When your manager walks into that 1:1 with their boss, their boss wants to hear that you have, single-handedly, written gigalines of code, 16 hours a day, clicked <3 on every CTO message in the Engineering channel on Slack, and managed to do so without making everyone else in the company hate you.
Nobody who controls your promotion ever actually reads your code, or understands your solutions. Nobody ever loads up your architecture diagram or your implementation when discussing your promotion. Something to keep in mind. People in a position to give out "career rewards" are too busy, distracted, and uninvested in you personally to pay attention to anything other than quick, easily observable and defensible impressions.
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!
I went to town on this in a blog a few years back "The Common Sense Guide to Not fucking up Your Business or Organization." <https://rodyne.com/?p=2024> as the action described in the original article is usually one of the first clues that something is wrong. I've seen many a good person leave companies and IT budgets subsequently balloon out of control with a completely laissez-faire attitude by senior management. I wish more CEO's would pick up on this stupidity.
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.
* 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.
It sounds like they had a previously complex (and I assume problematic) system to compare it to. When complexity is causing problems and the job is to simplify to get rid of problems, it will be rewarded.
If it was made simple from the start, it would have likely been seen as an easy and solved problem, and you never would have been brought in, as no one would ever think about it again.
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.