I had an interview question. What would you do if two different people were emailing a spreadsheet back and forth to track something?
I said I’d move them to google sheets. There was about five minutes of awkwardness after that as I was interviewing for software developer. I was supposed to talk about what kind of tool I’d build.
I found it kind of eye opening but I’m still not sure what the right lesson to learn was.
So my cofounder was talking to Stripe about an acquihire (this was after I’d left.) As part of it, he had to do a systems design interview.
He got the prompt, asked questions about throughput requirements (etc.), and said, “okay, I’d put it all in Postgres.” He was correct! Postgres could more than handle the load.
He gets a call from Patrick Collison saying that he failed the interview and asking what happened. He explained himself, to which Patrick said, okay, well yes you might be right but you also understand what the point of the interview is.
If the point of the interview was to test if the candidate can design something that can handle google-scale problems then maybe the interviewer shouldn't state throughput and availability requirements that can be satisfied by postgres
I feel like if that's the thought process, that should be stated up front
There's a ton of incredibly talented neurodivergent people in our ecosystem who would trip up on that question just because of how it's framed
Because how is the interviewee to know if you're testing for the technically sophisticated answer no one in their right mind would ever write or the pragmatic one?
I dont even think you need to be neurodivergent or anything to answer this question like the parent’s cofounder did.
From one side, we call ourselves problem solvers, on the other hand we are not satisfied with simple solutions to these problems.
If im interviewing for a job, i should be expected to behave and solve hypothetical problems the way id do it on the job. If that screws up your script, you probably suck at hiring and communicating your expectations.
> What would you do if two different people were emailing a spreadsheet back and forth to track something?
I realize this is part of an interview game, but perhaps the best response is still to ask why this is a problem in the first place before you launch into a technical masterpiece. Force the counterparty to provide specific (contrived) reasons that this practice is not working for the business. Then, go about it like you otherwise would have.
This is one of my favourite interview questions too. I ask a design question that technically could be solved using the specialist skillset I interview for but it would be insane to actually do that in the real world. It's a good opener to see how practical and open minded they really are.
The followup questions usually help, like: "What are they tracking?" and "What are the problems caused by using a spreadsheet?" That usually gives you a clue of the answer they're looking for. The answer might be bullshit, but you pass an interview by playing their game, not yours.
It's a culture fit question. When the culture is 'make everything ourselves' you're not a great culture fit. When the culture is 'just solve the problem', you fit in perfectly well.
The lesson to learn is that in-house development groups are often incentivized to “sell” custom software solutions to their organizations, as their existence (budget) relies on it.
As an interviewee it’s important to try and identify whether the group you’re interviewing with operates this way, literally: How will they get the money to pay for your salary? That way you avoid giving nom-starter answers to interview questions.
depends on what metric it is that _you_ want to optimize. i would have given the same answer, then aikidoed their confusion into some quick lecture on efficiency of software solutions in a business context and finally a segway into a project i worked on (or made up on a whim) of related relevance that i assume would be more interesting to talk about instead. but given my rather unimpressive career i'd suggest to not listen to me.
Honestly, if I'd have heard that, I'd hire you in a heartbeat, you solved the problem without increasing total cost of ownership to the company and meant we could move forwards
I'd actually trust you to take on harder problems
Doesn't really matter what the situation is, there's much more that can be achieved in my book with that kind of mindset :)
I'm also of the opinion that in an increasingly LLM software written world, being able to have this kind of mindset will actually be really valuable
I mean you gave the right answer imho. Software engineers are just business people whose main tool is coding. You know you're good if you don't reach for the hammer when you don't have a nail.
> At least from the point of view of the interviewer, this was the point where they should give you a polite "hey, play along" nudge.
That may be the game, but we all know it's bullshit, and we shouldn't be playing along.
If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software
> If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software
All interviews are contrived / artificial situations: The point is to understand the candidate's thought processes. Furthermore, we're getting Bilsbie's (op) take on the situation, there may be context that the interviewer forgot to mention or otherwise Bilsbie didn't understand / remember.
Specifically, if (the hypothetical situation) is a critical business process that they need an audit log of; or that they want to scale, this becomes an exercise in demonstrating that the candidate knows how to collect requirements and turn a manual process into a business application.
The interviewer could also be trying to probe knowledge of event processing, ect, ect, and maybe came up with a bad question. We just don't know.
Given that Bilsbie can't read their interviewer's mind, there's no way to know if that's what the interviewer wanted, or if the interviewer themselves was bad at interviewing candidates.
AI coding tools are making this problem worse in a subtle way. When an agent can generate a "scalable event-driven architecture" in 5 minutes, the build cost of complexity drops to near zero. But the maintenance cost doesn't.
So now you get Engineer B's output even faster, with even more impressive-sounding abstractions, and the promotion packet writes itself in minutes too. Meanwhile the actual cost - debugging, onboarding, incident response at 3am - stays exactly the same or gets worse, because now nobody fully understands what was generated.
The real test for simplicity has always been: can the next person who touches this code understand it without asking you? AI-generated complexity fails that test spectacularly.
Not sure if you're kidding or not, but to write great maintable code, you need a lot of understanding that a LLM just doesn't have, like history, business context, company culture etc. Also, I doubt that in it's training data it has a lot of good examples of great maintainable code to pull from.
Admitting you've spent two decades on a career stuck working in the kind of sweatshops that hire people who can't actually code isn't much of a flex, and certainly doesn't lend a whole lot of credence to your argument.
Sometimes, as in the bilsbi's top level comment, the solution is to use a free tool/library/product that already exists. The solution is not always to write new code, but the agent will happily do it.
Maybe that's "the manager's job", but that's just passing the buck and getting a worse solution. Every level of management should be looking for the best solution.
It’s not even about perfectionism. Code’s value is about processing data. Bad code do it wrongly and if you have strange code on top of that, you cannot correct the course. Happy path are usually the low hanging fruits. What makes developing software hard is thinking about all the failure and edge cases.
I worked at Amazon 2005-2008 as a Software Dev Engineer. To hammer home company culture, there were two awards which could be awarded at the Quarterly All-hands meeting
* The "Just Do It" Award which recognized someone just fixing some obvious problem at was in front of them but not responsibility
* The "Door Desk" Award for frugality, named in honour of the basic door-frame-four-leg desk everyone worked on.
In many ways, the Door Desk award was for simplicity. I remember, one time, someone got an award for getting rid of some dumb operations room with some big unused LCD TVs. When you won these awards, you rarely got any kind of reward. It was just acknowledgement at the meeting. But that time, they literally gave the guy the TVs.
I forget who said it, but it seems that AI is basically an amplifier of the talents (or lack of them) of whoever is wielding the tool.
In the hands of an experienced developer/designer, AI will help them achieve a good result faster.
In the hands of someone inexperienced, out of their depth, AI will just help them create a mess faster, and without the skill to assess what's been generated they may not even know it.
I am the type of engineer who prefers simplicity and I have not found a way to make AI increase the simplicity of code I'm working on. If left to its own devices, Claude absolutely loves adding more member variables, wrapper functions, type conversions, rather than, say, analyzing and eliminating redundancies. So my experience is that AI is more closely aligned with the engineer type for whom the solution is always "add more code", rather than whatever its human manager would do.
> The interviewer is like: “What about scalability? What if you have ten million users?”
This reminded me of how much more fun I find it to work on software that always only has one user, and where scaling problems are related solely to the data and GUI interaction design.
Really you can. You look at the engineers who create steaming piles, and you look at the ones who don't. Over a year or two, the difference is easy to spot. For people who care to spot it.
If there's no competent front-line technical management who can successfully make this simple comparison, then, sure, in that case the team may be fucked.
I think this is often true and it's the limiting factor that prevents complexity from spiraling out of control. But there's also a certain type of engineer who generates Rube Goldberg code that actually works, not robustly, but well enough. A mad genius high on intelligence and low on wisdom, let's say. This is who can spin complexity into self reward.
Yes, and ironically there are promotion ladders that explicitly call out "staff engineers identify problems before they become an issue". But we all know that in reality no manager-leader is ever going to fix problems eagerly, if they even agree with someone's prediction that that thing is really going to become a problem.
I once used the analogy of the PM coming to the shop with a car that had a barely running engine and broken windows, and he's only letting me fix the windows.
His response: "I can sell a good looking car and then charge them for a better running engine"...
> "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%"
My experience is no one really gets promoted/rewarded for these types of things or at least not beyond an initial one-off pat on the back. All anyone cares about is feature release velocity.
If it's even possible to reduce incidents by 80% then either your org had a very high tolerance for basically daily issues which you've now reduced to weekly, or they were already infrequent enough that 80% less takes you from 4/year to 1/year.. which is imperceptible to management and users.
> All anyone cares about is feature release velocity.
And at the same time it's impossible to convince tech illiterate people that reducing complexity likely increases velocity.
Seemingly we only get budget to add, never to remove. Also for silver bullets, if Big Tech promises a [thing] you can pay for that magically resolves all your issues, management seems enchanted and throws money at it.
You can reduce a single type of incident by 80%. The overall incident rate for this particular type wasn't high enough to kill your company, but it's still a big number on your promotion packet.
The "time to market" folks finally have everything they could hope for, let's see all of that business value they claim is being missed due to pesky things like security, quality, and scalability checks.
One of our interviews is a technical design question that asks the candidate to design a web-based system for public libraries. It explicitly tests for how simple they can keep it, starting at "a single small town library" scale and then changing the requirements to "every library in the country". The top ever performance was someone who answered that by estimating that even at max theoretical scale, all you need a medium sized server and Postgres.
I have 100% failed interviews by giving that answer when their definition of scale was 10,000!!!! req/sec. Like sorry dude in 2026 that's not much different than 10 req/sec and my original design would work just fine... But that's what happens when your interviewer is a "senior" 24 year old just reading off the prompt.
Most people forget that the early web was built in server closets on-site handling hundreds of requests per second. The business was sold hyperscalers because devs wanted more servers and were tired of arguing WHY they wanted more servers. Then they got sold on Highly Available services because every second you're down is a dollar, or more, lost. Nobody mentioned that the cost of building and maintaining it costs more than the money you'd lose except for the largest of organizations.
Don't even get me started on the resume-driven development that came along with it.
And maybe I'm completely wrong. This is a perspective of one.
Honestly I think that the real result of this is developers that don't really understand the underlying tooling and invent all sorts of bad architectures.
One common example I cite is at one job I owned Kafka and RabbitMQ clusters. Zero consideration was given to message size recommendations and we had incidents on the regular because some application was shoving multi-hundred megabyte messages into RMQ. They'd do other stupid shit like not ack their messages which would cause them to never be removed from local disk. This was a huge org, public company, hiring "only the best and brightest".
Management endlessly just threw more hardware at it rather than make the engineers fix their obviously bad architecture. What a headache. Some companies take the "prioritize engineer happiness" thing right off a cliff.
I keep reading this online but never encounter it in real life. People I work with and for like simple solutions that don't add complexity. It saves them time and money. I really wonder how is it that some people seem to encounter this toxic mentality so much that they assume it is universal. Is it a FAANG/US culture thing where everyone acts based on corrupted incentives?
Actually I have seen successful promotion packets based on elimination of complexity. When maintenance of a complex system becomes such a burden that even a director is aware of it, "eliminating toil" is a staff level skill.
More than once I have seen the same project yield two separate promotions, for creating it and deleting it. In particular this happens when the timescale of projects is longer than a single engineer's tenure on a given team.
But yes, avoiding complexity is rarely rewarded. The only way in which it helps you get promoted is that each simple thing takes less time and breaks less often, so you actually get more done.
Long rant, but the author never defines what he means by "simple". He heavily hints at smaller changeset == simpler.
Too often the smallest changeset is, yes, simple, but totally unaware of the surrounding context, breaks expectations and conventions, causes race conditions, etc.
The good bit in tfa is near the end:
> when someone asks “shouldn’t we future-proof this?”, don’t just cave and go add layers. Try: “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, but showing you’ve done your homework. You considered the complexity and chose not to take it on.
I think Rich Hickey's talk about simple is great for defining these terms (literally). He describes how the roots of "simplex" mean single braid, which compares to the twisting & coupling with complexity; an apt visual for software development. He also differentiates simple/complex from easy/hard, which is important.
The answer to this is almost always "NO" in my experience, because no one ever actually has good suggestions when it comes up. It's never "should we choose a scalable compute/database platform?" It's always "should we build a complex abstraction layer in case we want to use multiple blob storage systems that will only contain the lowest common denominator of features of both AND require constant maintenance AND have weird bugs and performance issues because I think I'm smarter than AWS/Google AND ALSO we have no plans to actually DO that?"
I built a showback model at a prior org. Re-used shelfware for the POC, did the research on granular costs for storage, compute, real estate, electricity, HVAC maintenance, hardware amortization, the whole deal. Could tell you down to the penny how much a given estate cost on-prem.
Simple. Elegant. $0 in spend to get running in production, modest spend to expand into public cloud (licensing, mainly). Went absolutely nowhere.
Got RIFed. On the way out the door, I hear a whole-ass team did the same thing, using additional budget, with lower confidence results. The biggest difference of all? My model gave you the actual cost in local currency, theirs gave you an imagined score.
The complexity (cost of a team, unnecessary scoring) was rewarded, not the simplicity.
Dijkstra understood it 50 years ago, and again 26 years ago [1]. Nothing changes. Malpractice just propagate and there are zero incentives to build simple, small, and maintainable software.
If the company you work for just push for unnecessary complexity, get out of there! Don't fold!
> If the company you work for just push for unnecessary complexity, get out of there!
Why? We learn all these cool patterns and techniques to address existing complexity. We get to fight TRexes… and so we get paid good money (compared to other jobs). No one is gonna pay me 120K in europe to build simple stuff that can work in a single sqlite db with a php fronted.
Except now we get websites that need to download 20-25MB of "latest cool framework" to show you a blurb of text because programmers before you created unnecessary complexity that needs to be maintained forever.
The honest opinion no one wants to hear is that programmers do not deserve the money they are paid for because MOST of the time what it's really needed is a "single sqlite db with a php frontend".
> In design reviews, when someone asks “shouldn’t we future-proof this?”, don’t just cave and go add layers.
In fact, simplicity often is the best future-proofing. Complex designs come with maintenance costs, so simple designs are inherently more robust to reorgs, shifted priorities, and team downsizing.
> 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+.
> But for Engineer A’s work, there’s almost nothing to say. “Implemented feature X.” Three words. Her work was better. But it’s invisible because of how simple she made it look. You can’t write a compelling narrative about the thing you didn’t build. Nobody gets promoted for the complexity they avoided.
Well, Engineer A's manager should help her writing a better version of her output. It's not easy, but it's their work. And if this simpler solution was actually better for the company, it should be highlighted how in terms that make sense for the business. I might be naive and too optimistic but good engineers with decent enough managers will stand out in the long run. That doesn't exclude that a few "bad" engineers can game their way up at the same time, even in functional organizations. though.
There's a significant asymmetry though, it's not just a bit more work. I'm a bit cynical here, but often it's easier to just overengineer and be safe than to defend a simple solution; obviously depending on the organization and its culture.
When you have a complex solution and an alternative is stacked up against it, everything usually boils down to a few tradeoffs. The simple solution is generally the one with the most tradeoffs to explain: why no HA, why no queuing, why no horizontally scalable, why no persistence, why no redundancy, why no retry, etc. Obviously not all of them will apply, but also obviously the optics of the extensive questioning will hinder any promotion even if you successfully justify everything.
> And if this simpler solution was actually better for the company, it should be highlighted[…]
Simpler than what? The reason this phenomenon is so pervasive in the first place is that people can’t know the alternatives. To a bystander (ie managers), a complex solution is proof of a complex problem. And a simple solution, well anyone could have done that! Right?
If we want to reward simplicity we have to switch reference frame from output (the solution), to input (the problem).
I'm (also) an EM, I've been a pure EM in some roles in my career and I really struggle to understand these pain points that many people bring up. Isn't a manager job to know what their managees are focused on over a period of time? Shouldn't be they aware of the projects the team is working on? As EM and most probably previously engineers, shouldn't they know already why simple solutions are good?
In larger systems, what looks like “overengineering” can be deliberate risk management. In my experience, senior engineers do get promoted for simplicity but only when they can articulate the trade-offs and the future costs they are avoiding.
You need the tension between both, or else either approach at most levels of systems, whether its an app or a corporation, tends to lead to toxic failures modes.
It could be something overbuilt, large organization structures. Brittle solutions that are highly performant until they break. Or products/offerings that don't grow for similar reasons, simpler-is-better, don't compete with yourself. Or those that grow the wrong way-- too many, much to manage, frailty through complexity, sku confusion.
Alternatively, things that are allowed to grow with some leeway, some caution, and then pruned back.
There's failure modes in any of these but the one I see most often is overreaching concern for any single one.
Maybe I am naive but I still believe that simplicity leads to personal wins in the long run. Having simpler system designs lead to velocity and eventually you become known as the "team that can deliver".
Any system that make rewarding path based on individual contributions as this defect. As opposed to one insuring that the overall result benefits is evenly distributed among all the engaged parties.
The obvious outcome will be that the most skilled pretenders optimizing for their selfish profit narrow view, no matter what the consequences will be for the collectivity on large scale and at long terms.
Assuming: simplicity === no unnecessary complexity.
In my (limited) experience as an engineer and manager, leadership (e.g., a VP) didn’t like (or reward) simplicity. Simple solutions often meant smaller teams, which wasn’t something they were pushing for, especially pre-2024. I do think this is slowly evolving, and that the best leaders now focus on removing unnecessary complexity and improving velocity.
Nyeah ... but people can get promoted for consistently shipping stuff that works, on time. And people can get sidelined for consistently taking 10x as much time to provide the same business value. That may not be the rule, and it may not always be obvious in the short term who is sidelined. But it can happen.
It can even happen that the tag "very smart" gets attached to those sidelined engineers. That's not necessarily a compliment.
The push for simplicity can't be at the time of recognition. It has to be during the building, so that by the time the thing gets built, it's the simplest thing that met the need.
Can you actually imagine a promo committee evaluating the technical choices? "Ok, this looks pretty complex. I feel like you could have just used a DB table, though? Denied."
Absolutely not! That discussion happens in RFCs, in architecture reviews, in hallway meetings, and a dozen other places.
If you want simplicity, you need to encourage mentorship, peer review, and meaningful participation in consensus-building. You need to reward team-first behavior and discourage lone-wolf brilliance. This is primarily a leadership job, but everybody contributes.
But that's harder than complaining that everything seems complicated.
>Can you actually imagine a promo committee evaluating the technical choices? "Ok, this looks pretty complex. I feel like you could have just used a DB table, though? Denied."
A committee with no skin in the game, who knows? But a manager who actually needs stuff done, absolutely.
Part of this from what I've seen is a large company problem, where developers exist underneath a thick layer of middle management.
In smaller companies it's a lot easier to express the distinctions and values of simplicity to ears that might actually appreciate it (so long as you can translate it into what they value - simple example is pointing out that you produced the same result in much less time, and that you can get more done on overall feature/task level as a result).
Engineer B who can get that over complex solution working is the person you will turn to when complexity is required for the problem. They have experience in getting it to work, and such they really are worth more.
The real question is how do you tell engineer A who can figure out how to make the complex problems simple from engineer C who can't handle complexity and so writes simple solutions when the complex one is needed.
Not really, because even when complexity is required, the last thing you want is even more, unneeded complexity. There is no guarantee that the kind of complexity B brought to a problem is the exact same kind you're going to need somewhere else. It turns out that complexity is, shall we say, more complex than that.
I’ve definitely consistently seen people who can take a wildly complex bug-ridden Rube Goldberg machine that was impossible to change and break it down into a simple understandable system get promoted. These people are generally the best engineers in the org and a get reputation for that.
Not just simplicity, we are wired towards additive solutions, not substractive ones, on a problem we try to add more elements instead of taking out existing ones. And are those additions what counts, what are seen, not the invisible, missing ones.
Whatever is going on with each 'f' in this font is breaking my brain. Feels like the drunk goggles equivalent of dyslexia.
I don't think this phenomenon is unique to programming. My plumber was explaining how he put in a manifold and centralized whole-house off valve accessible indoors and I was like, okay, thanks? I can just turn it off at the street.
Only established professionals have the status and self-confidence to show restraint. I think that explains interviews.
Essentially, there are two parallel teams, one is seen constantly huddling together, working late, fixing their (broken) service. The other team is quiet, leaves on time, their service never has serious issues. Which do you think looks better from the outside?
People always overcomplicate this. Companies want to get the most out of their employees, for the least amount of money paid.
Promotions are supposed to incentivise people to stay, rather than leave. If the company never promoted anyone, people would leave. So there needs to be a path for promoting people. But that process doesn’t have to be transparent, or consistent, or fair - in-fact it rarely is.
You promote people who consistently overdeliver, on time, at or below cost, who are a pleasure to work with, who would benefit the company long term, who would be a pain to lose. A key precondition is that such people consistently get more done compared to other people with equal pay, otherwise, they don’t stand out and they are not promotion material.
What counts as overdelivering will vary based on specific circumstances. It’s a subjective metric. Are you involved with a highly visible project, or are you working on some BS nobody would miss if it got axed? Are you part of a small team, or are you in a bloated, saturated org? Are you the go-to person when shit hits the fan, or are you a nobody people don’t talk to? Are you consistent, or are you vague and unpredictable? Does your work impact any relevant bottom lines, or are you just part of a cost centre? It really isn’t rocket science, for the most part.
Numerous times I've seen promotions going to people who were visible but didn't do the actual work. Those who share the achievements on Slack, those who talk a lot, get to meetings with directors, those who try to present the work.
For the vast majority of people and cases, it really is that simple - but like I already said, "the process doesn’t have to be transparent, or consistent, or fair - in-fact it rarely is". There are exceptions to every rule, but for most people, it really does come down to some self reflection:
1. Do I consistently deliver more (in output, impact, or reliability) than peers at my pay level?
2. Is my work visible and tied to meaningful business outcomes, rather than low-impact tasks?
3. Am I known as dependable and easy to work with, especially under pressure?
4. Would the company feel a real loss-operationally or financially-if I left?
5. Have I made myself clearly more valuable to the organization than what I currently cost?
Charlie Munger once said >>> Show me the incentive, I will show you the outcome
Problem is in big tech -- the incentives are all aligned towards complex stuff
you wanna get promoted - do complex stuff that doesn't make sense. If you get promoted, then it also boosts the performance of your manager.
the only way to escape this nonsense is to work at smaller companies
right now you've people advocating for A.I coded solutions yet never realizing that A.I solutions result in a convoluted mess since A.I never possesses the ART of software engineering i.e knowing what to cut out
It's not just that it looks good, there is constant pressure from other Engineers that we should "Do it right" and "Plan for the future" even if the future is murky and every design choice we take for scalability is probably just constraints that will hinder us if the requirements change.
as a manager its constant fighting the pressure to build "Great software" that is way above what the company needs instead building working software that addresses customer needs in a timely manner.
My dude we are s startup with two servers and 20 customers, we do not need infinite scalability.
I interviewed at a company that used a simple project to screen candidates. It was implementing a cash register checkout system. The task was soo simple that I couldn't figure out what they were looking for. So I implemented the simplest thing possible. I got the job partially because they were impressed by my utterly simple solution. I helped evaluate other candidates given the exact same problem and it's amazing how some people dialed up the complexity to 11. None of them passed the screening.
Promotion Driven Development at its finest. There's no good way to fix this without better teams and less Lord of the Flies style management. Servant leadership helps here, but if your team is adversarial in nature there is no escape. A manager that needs an exciting story to get a feather in their hat will take the story every time over "+20 -8000" commit style developers. Your product will suffer accordingly.
A lot of this boils down to promo system being so systematized. I've never heard of people in any other field min/max their promotions as hard along with all of the expert jargon in any other field I've worked in. Packets, peers, comp, other co comps, what your boss thinks of you, what your boss thinks of your peers (nee: competitors), and the inevitable crash out when they don't get the promotion. All part of the bigco experience! I feel like when we systematized comp into ranks Lx, Ly we gave up our leverage a little bit.
Being able to solve problems with true simplicity is a master’s skill. The skill to recognize simplicity and its value is a skill as well.
You can try to explain this OP’s concept to a stakeholder in a 1000 different sensible ways and you’ll get blinking deer-in-headlight eyes back at you.
This skill is hard-earned and, so, rare.
Therefore, many hierarchies are built on sufficient mediocrity top to bottom.
Which works because bottom line doesn’t often matter in software dev anyway.
And even when it does matter it’s multiplicatively rare to have a hierarchy or even the market that it tries to serve who can build, comprehend, handle high power::complexity systems, products, tools.
I'm trying to sell simplicity to my target market, who I would call "semi-tech literate". Maybe it's stupid and I should sell whatever Forbes thinks is cool, but I just can't shake this feeling that I should be solving actual business problems.
We failed a bid for a project because of simplicity. We were to migrate a service running on an on-prem Kubernetes installation and a three, or five, node Apache Cassandra cluster to Azure.
The service saw maybe a few hundred transaction per day, total database size: 2 - 3GB. The systems would hold data about each transaction, until processed and then age it out over three months, making the database size fairly stable.
Talking to a developer advocate for Azure we learned that CosmosDB would get a Cassandra API and we got access to the preview. The client was presented with a solution were the service would run as a single container in Azure Websites and using CosmosDB as the database backend. The whole thing could run within the free tier at that point. Massive saving, much easier to manage. We got rejected because the solution didn't feel serious and to simplistic for an organisation of their scale.
On the other hand I also once replaced a BizzTalk server with 50 lines of C# and that was well received by the client, less so of my boss who now couldn't keep sending the bill for a "BizzTalk support contract" (which we honestly couldn't honour anyway).
If I was an engineering manager in an org which actually valued getting sh*t done - vs. bragging rights, head counts, and PHB politics - then I'd notice within a month that Engineer A (who the article has shipping in a couple days) got far more done then Engineer B (who needed 3 weeks).
And long before performance review time, I'd have mentioned further up that A was looking like a 5X engineer - best if we keep her happy.
I once hacked a spreadsheet in a week that was good enough to not embark on a multiple-months 3-devs project.
In the same team, I tweaked a configuration file for distributed calculations that shaved 2 minutes of calculation on an action that the user would run thirty times a day.
I got paid all right.
People don't give a shit about complexity or simplicity. They care about two things:
1. Does it work
2. How soon can you ship
There is a third thing that stakeholders really like: when you tell them what they should be building, or not building.
I had an interview question. What would you do if two different people were emailing a spreadsheet back and forth to track something?
I said I’d move them to google sheets. There was about five minutes of awkwardness after that as I was interviewing for software developer. I was supposed to talk about what kind of tool I’d build.
I found it kind of eye opening but I’m still not sure what the right lesson to learn was.
So my cofounder was talking to Stripe about an acquihire (this was after I’d left.) As part of it, he had to do a systems design interview.
He got the prompt, asked questions about throughput requirements (etc.), and said, “okay, I’d put it all in Postgres.” He was correct! Postgres could more than handle the load.
He gets a call from Patrick Collison saying that he failed the interview and asking what happened. He explained himself, to which Patrick said, okay, well yes you might be right but you also understand what the point of the interview is.
They made him do it again and he passed.
If the point of the interview was to test if the candidate can design something that can handle google-scale problems then maybe the interviewer shouldn't state throughput and availability requirements that can be satisfied by postgres
I feel like if that's the thought process, that should be stated up front
There's a ton of incredibly talented neurodivergent people in our ecosystem who would trip up on that question just because of how it's framed
Because how is the interviewee to know if you're testing for the technically sophisticated answer no one in their right mind would ever write or the pragmatic one?
I dont even think you need to be neurodivergent or anything to answer this question like the parent’s cofounder did.
From one side, we call ourselves problem solvers, on the other hand we are not satisfied with simple solutions to these problems. If im interviewing for a job, i should be expected to behave and solve hypothetical problems the way id do it on the job. If that screws up your script, you probably suck at hiring and communicating your expectations.
Sorry, I didn't get it. What was the 'right' answer?
> you also understand what the point of the interview is
Exactly, it's also a test of ability to conform. Especially useful to weed out rogue behavior picked up in startups.
No, the point was to demonstrate how you’d design a complex system.
If a valid answer was “just use Postgres” then it just wasn’t a very good interview question.
In real life, the answer almost certainly would be “just use Postgres” and everyone would be happy.
> okay, well yes you might be right but you also understand what the point of the interview is.
So the point is? I honestly dont understand.
Remember you're interviewing them just as much as they are interviewing you.
> What would you do if two different people were emailing a spreadsheet back and forth to track something?
I realize this is part of an interview game, but perhaps the best response is still to ask why this is a problem in the first place before you launch into a technical masterpiece. Force the counterparty to provide specific (contrived) reasons that this practice is not working for the business. Then, go about it like you otherwise would have.
This is one of my favourite interview questions too. I ask a design question that technically could be solved using the specialist skillset I interview for but it would be insane to actually do that in the real world. It's a good opener to see how practical and open minded they really are.
The followup questions usually help, like: "What are they tracking?" and "What are the problems caused by using a spreadsheet?" That usually gives you a clue of the answer they're looking for. The answer might be bullshit, but you pass an interview by playing their game, not yours.
This! It’s better to assume that you don’t know some context than go with what appears to be the most pragmatic answer. Even in the real world.
It's a culture fit question. When the culture is 'make everything ourselves' you're not a great culture fit. When the culture is 'just solve the problem', you fit in perfectly well.
The lesson was that sometimes the interviewee can be more competent than the interviewer and they should run.
Or maybe this: https://news.ycombinator.com/item?id=47247719
I would ask, why are they emailing it? Maybe there's a good reason they can't use sheets.
The lesson to learn is that in-house development groups are often incentivized to “sell” custom software solutions to their organizations, as their existence (budget) relies on it.
As an interviewee it’s important to try and identify whether the group you’re interviewing with operates this way, literally: How will they get the money to pay for your salary? That way you avoid giving nom-starter answers to interview questions.
depends on what metric it is that _you_ want to optimize. i would have given the same answer, then aikidoed their confusion into some quick lecture on efficiency of software solutions in a business context and finally a segway into a project i worked on (or made up on a whim) of related relevance that i assume would be more interesting to talk about instead. but given my rather unimpressive career i'd suggest to not listen to me.
I had a similar idea once when answering a Stack Overflow question[0].
[0] https://stackoverflow.com/a/1831841/61938
Honestly, if I'd have heard that, I'd hire you in a heartbeat, you solved the problem without increasing total cost of ownership to the company and meant we could move forwards
I'd actually trust you to take on harder problems
Doesn't really matter what the situation is, there's much more that can be achieved in my book with that kind of mindset :)
I'm also of the opinion that in an increasingly LLM software written world, being able to have this kind of mindset will actually be really valuable
I mean you gave the right answer imho. Software engineers are just business people whose main tool is coding. You know you're good if you don't reach for the hammer when you don't have a nail.
Probably that you didn't want the job?
At least from the point of view of the interviewer, this was the point where they should give you a polite "hey, play along" nudge.
> At least from the point of view of the interviewer, this was the point where they should give you a polite "hey, play along" nudge.
That may be the game, but we all know it's bullshit, and we shouldn't be playing along.
If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software
> If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software
All interviews are contrived / artificial situations: The point is to understand the candidate's thought processes. Furthermore, we're getting Bilsbie's (op) take on the situation, there may be context that the interviewer forgot to mention or otherwise Bilsbie didn't understand / remember.
Specifically, if (the hypothetical situation) is a critical business process that they need an audit log of; or that they want to scale, this becomes an exercise in demonstrating that the candidate knows how to collect requirements and turn a manual process into a business application.
The interviewer could also be trying to probe knowledge of event processing, ect, ect, and maybe came up with a bad question. We just don't know.
Given that Bilsbie can't read their interviewer's mind, there's no way to know if that's what the interviewer wanted, or if the interviewer themselves was bad at interviewing candidates.
AI coding tools are making this problem worse in a subtle way. When an agent can generate a "scalable event-driven architecture" in 5 minutes, the build cost of complexity drops to near zero. But the maintenance cost doesn't.
So now you get Engineer B's output even faster, with even more impressive-sounding abstractions, and the promotion packet writes itself in minutes too. Meanwhile the actual cost - debugging, onboarding, incident response at 3am - stays exactly the same or gets worse, because now nobody fully understands what was generated.
The real test for simplicity has always been: can the next person who touches this code understand it without asking you? AI-generated complexity fails that test spectacularly.
On the other hand, AI coding tools make it relatively easy to set and apply policies that can help with this sort of thing.
I like to have something like the following in AGENTS.md:
## Guiding Principles - Optimise for long-term maintainability - KISS - YAGNI
Not sure if you're kidding or not, but to write great maintable code, you need a lot of understanding that a LLM just doesn't have, like history, business context, company culture etc. Also, I doubt that in it's training data it has a lot of good examples of great maintainable code to pull from.
Neither do most humans writing such code, i have seen llms generate better code than 90% of coders I have seen in the last 20 years
Admitting you've spent two decades on a career stuck working in the kind of sweatshops that hire people who can't actually code isn't much of a flex, and certainly doesn't lend a whole lot of credence to your argument.
He isn't kidding. I have a directive to write the shortest, least complicated, readable business code and it makes a huge difference
Sometimes, as in the bilsbi's top level comment, the solution is to use a free tool/library/product that already exists. The solution is not always to write new code, but the agent will happily do it.
Maybe that's "the manager's job", but that's just passing the buck and getting a worse solution. Every level of management should be looking for the best solution.
"Be sure to remember software is a sociotechnical system and dont fall prey to the Mechanistic myth"
It's a bad time to be an altruistic perfectionist, tell you what.
Avoid hands-on tech/team lead positions like hell.
that second line is so underrated
It’s not even about perfectionism. Code’s value is about processing data. Bad code do it wrongly and if you have strange code on top of that, you cannot correct the course. Happy path are usually the low hanging fruits. What makes developing software hard is thinking about all the failure and edge cases.
The flip side of this is that languages who have a major selling point of maintainability just had their value increase dramatically.
Simplicity is a driver for better abstractions. But now with AI, will we even develop new abstractions?
I was in charge of cleaning up a slop codebase by someone who has barely even heard of 'coding' before. Let's just say, it was abstract.
I worked at Amazon 2005-2008 as a Software Dev Engineer. To hammer home company culture, there were two awards which could be awarded at the Quarterly All-hands meeting * The "Just Do It" Award which recognized someone just fixing some obvious problem at was in front of them but not responsibility * The "Door Desk" Award for frugality, named in honour of the basic door-frame-four-leg desk everyone worked on.
In many ways, the Door Desk award was for simplicity. I remember, one time, someone got an award for getting rid of some dumb operations room with some big unused LCD TVs. When you won these awards, you rarely got any kind of reward. It was just acknowledgement at the meeting. But that time, they literally gave the guy the TVs.
I forget who said it, but it seems that AI is basically an amplifier of the talents (or lack of them) of whoever is wielding the tool.
In the hands of an experienced developer/designer, AI will help them achieve a good result faster.
In the hands of someone inexperienced, out of their depth, AI will just help them create a mess faster, and without the skill to assess what's been generated they may not even know it.
I am the type of engineer who prefers simplicity and I have not found a way to make AI increase the simplicity of code I'm working on. If left to its own devices, Claude absolutely loves adding more member variables, wrapper functions, type conversions, rather than, say, analyzing and eliminating redundancies. So my experience is that AI is more closely aligned with the engineer type for whom the solution is always "add more code", rather than whatever its human manager would do.
What about someone inexperienced but skeptical, using AI to learn + fix their own code before opening the PR?
Side note:
> The interviewer is like: “What about scalability? What if you have ten million users?”
This reminded me of how much more fun I find it to work on software that always only has one user, and where scaling problems are related solely to the data and GUI interaction design.
Sure they do. You just need to spell it out in business terms, not tech terms:
"Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%"
Simplicity for its own sake is not valued. The results of simplicity are highly valued.
You can't measure the impact of not creating a steaming pile of complexity.
Really you can. You look at the engineers who create steaming piles, and you look at the ones who don't. Over a year or two, the difference is easy to spot. For people who care to spot it.
If there's no competent front-line technical management who can successfully make this simple comparison, then, sure, in that case the team may be fucked.
I think this is often true and it's the limiting factor that prevents complexity from spiraling out of control. But there's also a certain type of engineer who generates Rube Goldberg code that actually works, not robustly, but well enough. A mad genius high on intelligence and low on wisdom, let's say. This is who can spin complexity into self reward.
Those verbs (reduced, decreased, increased) all assume the situation was "bad" already. Avoiding that in the initial design is what's poorly rewarded.
Building a system that's fast on day one will not usually be rewarded as well as building a slow system and making it 80% faster.
Yes, and ironically there are promotion ladders that explicitly call out "staff engineers identify problems before they become an issue". But we all know that in reality no manager-leader is ever going to fix problems eagerly, if they even agree with someone's prediction that that thing is really going to become a problem.
Absolutely. And if you asked them if they're rather have it sooner, or keep it simpler, they'd pick "sooner" every time.
I once used the analogy of the PM coming to the shop with a car that had a barely running engine and broken windows, and he's only letting me fix the windows.
His response: "I can sell a good looking car and then charge them for a better running engine"...
https://www.youtube.com/watch?v=T4Upf_B9RLQ hits a little too close to home.
> "Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%"
My experience is no one really gets promoted/rewarded for these types of things or at least not beyond an initial one-off pat on the back. All anyone cares about is feature release velocity.
If it's even possible to reduce incidents by 80% then either your org had a very high tolerance for basically daily issues which you've now reduced to weekly, or they were already infrequent enough that 80% less takes you from 4/year to 1/year.. which is imperceptible to management and users.
> All anyone cares about is feature release velocity.
And at the same time it's impossible to convince tech illiterate people that reducing complexity likely increases velocity.
Seemingly we only get budget to add, never to remove. Also for silver bullets, if Big Tech promises a [thing] you can pay for that magically resolves all your issues, management seems enchanted and throws money at it.
You can reduce a single type of incident by 80%. The overall incident rate for this particular type wasn't high enough to kill your company, but it's still a big number on your promotion packet.
This used to be true. Companies love efficiency. How does this stack up with modern AI? Seems those metrics would go in the opposite directions.
The "time to market" folks finally have everything they could hope for, let's see all of that business value they claim is being missed due to pesky things like security, quality, and scalability checks.
Never seen these metrics in real life, especially in engineering.
You are citing negative metrics. The reality is that companies only care about positive metrics: increase marginal revenue by 30%
That's regardless of the lip service they pay to cost cutting or risk reduction. It will only get worse, in the AI economy it's all about growth.
One of our interviews is a technical design question that asks the candidate to design a web-based system for public libraries. It explicitly tests for how simple they can keep it, starting at "a single small town library" scale and then changing the requirements to "every library in the country". The top ever performance was someone who answered that by estimating that even at max theoretical scale, all you need a medium sized server and Postgres.
I have 100% failed interviews by giving that answer when their definition of scale was 10,000!!!! req/sec. Like sorry dude in 2026 that's not much different than 10 req/sec and my original design would work just fine... But that's what happens when your interviewer is a "senior" 24 year old just reading off the prompt.
10,000!!!! is such a huge number I don't think we could even represent with a computer.
Being obviously pedantic here, I agree with what you meant.
Most people forget that the early web was built in server closets on-site handling hundreds of requests per second. The business was sold hyperscalers because devs wanted more servers and were tired of arguing WHY they wanted more servers. Then they got sold on Highly Available services because every second you're down is a dollar, or more, lost. Nobody mentioned that the cost of building and maintaining it costs more than the money you'd lose except for the largest of organizations.
Don't even get me started on the resume-driven development that came along with it.
And maybe I'm completely wrong. This is a perspective of one.
Honestly I think that the real result of this is developers that don't really understand the underlying tooling and invent all sorts of bad architectures.
One common example I cite is at one job I owned Kafka and RabbitMQ clusters. Zero consideration was given to message size recommendations and we had incidents on the regular because some application was shoving multi-hundred megabyte messages into RMQ. They'd do other stupid shit like not ack their messages which would cause them to never be removed from local disk. This was a huge org, public company, hiring "only the best and brightest".
Management endlessly just threw more hardware at it rather than make the engineers fix their obviously bad architecture. What a headache. Some companies take the "prioritize engineer happiness" thing right off a cliff.
Wait, so you are telling me that not every company builds Spotify on design system interview? Impossible
I keep reading this online but never encounter it in real life. People I work with and for like simple solutions that don't add complexity. It saves them time and money. I really wonder how is it that some people seem to encounter this toxic mentality so much that they assume it is universal. Is it a FAANG/US culture thing where everyone acts based on corrupted incentives?
Actually I have seen successful promotion packets based on elimination of complexity. When maintenance of a complex system becomes such a burden that even a director is aware of it, "eliminating toil" is a staff level skill.
More than once I have seen the same project yield two separate promotions, for creating it and deleting it. In particular this happens when the timescale of projects is longer than a single engineer's tenure on a given team.
But yes, avoiding complexity is rarely rewarded. The only way in which it helps you get promoted is that each simple thing takes less time and breaks less often, so you actually get more done.
Long rant, but the author never defines what he means by "simple". He heavily hints at smaller changeset == simpler.
Too often the smallest changeset is, yes, simple, but totally unaware of the surrounding context, breaks expectations and conventions, causes race conditions, etc.
The good bit in tfa is near the end:
> when someone asks “shouldn’t we future-proof this?”, don’t just cave and go add layers. Try: “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, but showing you’ve done your homework. You considered the complexity and chose not to take it on.
I think Rich Hickey's talk about simple is great for defining these terms (literally). He describes how the roots of "simplex" mean single braid, which compares to the twisting & coupling with complexity; an apt visual for software development. He also differentiates simple/complex from easy/hard, which is important.
https://www.youtube.com/watch?v=SxdOUGdseq4
> shouldn’t we future-proof this?
The answer to this is almost always "NO" in my experience, because no one ever actually has good suggestions when it comes up. It's never "should we choose a scalable compute/database platform?" It's always "should we build a complex abstraction layer in case we want to use multiple blob storage systems that will only contain the lowest common denominator of features of both AND require constant maintenance AND have weird bugs and performance issues because I think I'm smarter than AWS/Google AND ALSO we have no plans to actually DO that?"
/I'm not bitter...
this might help https://hammerproject.com/2023/07/28/complexity.html
Spitting facts, here.
I built a showback model at a prior org. Re-used shelfware for the POC, did the research on granular costs for storage, compute, real estate, electricity, HVAC maintenance, hardware amortization, the whole deal. Could tell you down to the penny how much a given estate cost on-prem.
Simple. Elegant. $0 in spend to get running in production, modest spend to expand into public cloud (licensing, mainly). Went absolutely nowhere.
Got RIFed. On the way out the door, I hear a whole-ass team did the same thing, using additional budget, with lower confidence results. The biggest difference of all? My model gave you the actual cost in local currency, theirs gave you an imagined score.
The complexity (cost of a team, unnecessary scoring) was rewarded, not the simplicity.
Dijkstra understood it 50 years ago, and again 26 years ago [1]. Nothing changes. Malpractice just propagate and there are zero incentives to build simple, small, and maintainable software. If the company you work for just push for unnecessary complexity, get out of there! Don't fold!
[1]: https://www.cs.utexas.edu/~EWD/ewd13xx/EWD1305.PDF
> If the company you work for just push for unnecessary complexity, get out of there!
Why? We learn all these cool patterns and techniques to address existing complexity. We get to fight TRexes… and so we get paid good money (compared to other jobs). No one is gonna pay me 120K in europe to build simple stuff that can work in a single sqlite db with a php fronted.
Except now we get websites that need to download 20-25MB of "latest cool framework" to show you a blurb of text because programmers before you created unnecessary complexity that needs to be maintained forever.
The honest opinion no one wants to hear is that programmers do not deserve the money they are paid for because MOST of the time what it's really needed is a "single sqlite db with a php frontend".
> If the company you work for just push for unnecessary complexity, get out of there!
If every company I know does this, how am I suppose to make money?
There are reasons for "unnecessary" complexity. Mainly cost and time.
Malpractice is exactly the word for this sort of shit.
> In design reviews, when someone asks “shouldn’t we future-proof this?”, don’t just cave and go add layers.
In fact, simplicity often is the best future-proofing. Complex designs come with maintenance costs, so simple designs are inherently more robust to reorgs, shifted priorities, and team downsizing.
> 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+.
> But for Engineer A’s work, there’s almost nothing to say. “Implemented feature X.” Three words. Her work was better. But it’s invisible because of how simple she made it look. You can’t write a compelling narrative about the thing you didn’t build. Nobody gets promoted for the complexity they avoided.
Well, Engineer A's manager should help her writing a better version of her output. It's not easy, but it's their work. And if this simpler solution was actually better for the company, it should be highlighted how in terms that make sense for the business. I might be naive and too optimistic but good engineers with decent enough managers will stand out in the long run. That doesn't exclude that a few "bad" engineers can game their way up at the same time, even in functional organizations. though.
> It's not easy, but it's their work.
There's a significant asymmetry though, it's not just a bit more work. I'm a bit cynical here, but often it's easier to just overengineer and be safe than to defend a simple solution; obviously depending on the organization and its culture.
When you have a complex solution and an alternative is stacked up against it, everything usually boils down to a few tradeoffs. The simple solution is generally the one with the most tradeoffs to explain: why no HA, why no queuing, why no horizontally scalable, why no persistence, why no redundancy, why no retry, etc. Obviously not all of them will apply, but also obviously the optics of the extensive questioning will hinder any promotion even if you successfully justify everything.
> And if this simpler solution was actually better for the company, it should be highlighted[…]
Simpler than what? The reason this phenomenon is so pervasive in the first place is that people can’t know the alternatives. To a bystander (ie managers), a complex solution is proof of a complex problem. And a simple solution, well anyone could have done that! Right?
If we want to reward simplicity we have to switch reference frame from output (the solution), to input (the problem).
I'm (also) an EM, I've been a pure EM in some roles in my career and I really struggle to understand these pain points that many people bring up. Isn't a manager job to know what their managees are focused on over a period of time? Shouldn't be they aware of the projects the team is working on? As EM and most probably previously engineers, shouldn't they know already why simple solutions are good?
Shipping a button in 2026… <https://www.youtube.com/watch?v=xE9W9Ghe4Jk>
In larger systems, what looks like “overengineering” can be deliberate risk management. In my experience, senior engineers do get promoted for simplicity but only when they can articulate the trade-offs and the future costs they are avoiding.
this is rare tho
You need the tension between both, or else either approach at most levels of systems, whether its an app or a corporation, tends to lead to toxic failures modes.
It could be something overbuilt, large organization structures. Brittle solutions that are highly performant until they break. Or products/offerings that don't grow for similar reasons, simpler-is-better, don't compete with yourself. Or those that grow the wrong way-- too many, much to manage, frailty through complexity, sku confusion.
Alternatively, things that are allowed to grow with some leeway, some caution, and then pruned back.
There's failure modes in any of these but the one I see most often is overreaching concern for any single one.
Maybe I am naive but I still believe that simplicity leads to personal wins in the long run. Having simpler system designs lead to velocity and eventually you become known as the "team that can deliver".
Any system that make rewarding path based on individual contributions as this defect. As opposed to one insuring that the overall result benefits is evenly distributed among all the engaged parties.
The obvious outcome will be that the most skilled pretenders optimizing for their selfish profit narrow view, no matter what the consequences will be for the collectivity on large scale and at long terms.
Assuming: simplicity === no unnecessary complexity.
In my (limited) experience as an engineer and manager, leadership (e.g., a VP) didn’t like (or reward) simplicity. Simple solutions often meant smaller teams, which wasn’t something they were pushing for, especially pre-2024. I do think this is slowly evolving, and that the best leaders now focus on removing unnecessary complexity and improving velocity.
Nyeah ... but people can get promoted for consistently shipping stuff that works, on time. And people can get sidelined for consistently taking 10x as much time to provide the same business value. That may not be the rule, and it may not always be obvious in the short term who is sidelined. But it can happen.
It can even happen that the tag "very smart" gets attached to those sidelined engineers. That's not necessarily a compliment.
The push for simplicity can't be at the time of recognition. It has to be during the building, so that by the time the thing gets built, it's the simplest thing that met the need.
Can you actually imagine a promo committee evaluating the technical choices? "Ok, this looks pretty complex. I feel like you could have just used a DB table, though? Denied."
Absolutely not! That discussion happens in RFCs, in architecture reviews, in hallway meetings, and a dozen other places.
If you want simplicity, you need to encourage mentorship, peer review, and meaningful participation in consensus-building. You need to reward team-first behavior and discourage lone-wolf brilliance. This is primarily a leadership job, but everybody contributes.
But that's harder than complaining that everything seems complicated.
>Can you actually imagine a promo committee evaluating the technical choices? "Ok, this looks pretty complex. I feel like you could have just used a DB table, though? Denied."
A committee with no skin in the game, who knows? But a manager who actually needs stuff done, absolutely.
Related: https://news.ycombinator.com/item?id=47242765
That is dead, but I vouched for it.
Part of this from what I've seen is a large company problem, where developers exist underneath a thick layer of middle management.
In smaller companies it's a lot easier to express the distinctions and values of simplicity to ears that might actually appreciate it (so long as you can translate it into what they value - simple example is pointing out that you produced the same result in much less time, and that you can get more done on overall feature/task level as a result).
There are two other reasons:
- CV-driven development. Adding {buzzword} with {in production} sounds better than saying I managed to make simple solutions faster.
- Job security. Those who wish to stay longer make things complicated, unsupportable, and unmaintainable, so they become irreplaceable.
Engineer B who can get that over complex solution working is the person you will turn to when complexity is required for the problem. They have experience in getting it to work, and such they really are worth more.
The real question is how do you tell engineer A who can figure out how to make the complex problems simple from engineer C who can't handle complexity and so writes simple solutions when the complex one is needed.
Not really, because even when complexity is required, the last thing you want is even more, unneeded complexity. There is no guarantee that the kind of complexity B brought to a problem is the exact same kind you're going to need somewhere else. It turns out that complexity is, shall we say, more complex than that.
I’ve definitely consistently seen people who can take a wildly complex bug-ridden Rube Goldberg machine that was impossible to change and break it down into a simple understandable system get promoted. These people are generally the best engineers in the org and a get reputation for that.
where do you work!? lol
Posted just yesterday: https://news.ycombinator.com/item?id=47242765
Not just simplicity, we are wired towards additive solutions, not substractive ones, on a problem we try to add more elements instead of taking out existing ones. And are those additions what counts, what are seen, not the invisible, missing ones.
Whatever is going on with each 'f' in this font is breaking my brain. Feels like the drunk goggles equivalent of dyslexia.
I don't think this phenomenon is unique to programming. My plumber was explaining how he put in a manifold and centralized whole-house off valve accessible indoors and I was like, okay, thanks? I can just turn it off at the street.
Only established professionals have the status and self-confidence to show restraint. I think that explains interviews.
This reminds me of this post from 2013 -- https://mikehadlow.blogspot.com/2013/12/are-your-programmers...
Essentially, there are two parallel teams, one is seen constantly huddling together, working late, fixing their (broken) service. The other team is quiet, leaves on time, their service never has serious issues. Which do you think looks better from the outside?
People always overcomplicate this. Companies want to get the most out of their employees, for the least amount of money paid.
Promotions are supposed to incentivise people to stay, rather than leave. If the company never promoted anyone, people would leave. So there needs to be a path for promoting people. But that process doesn’t have to be transparent, or consistent, or fair - in-fact it rarely is.
You promote people who consistently overdeliver, on time, at or below cost, who are a pleasure to work with, who would benefit the company long term, who would be a pain to lose. A key precondition is that such people consistently get more done compared to other people with equal pay, otherwise, they don’t stand out and they are not promotion material.
What counts as overdelivering will vary based on specific circumstances. It’s a subjective metric. Are you involved with a highly visible project, or are you working on some BS nobody would miss if it got axed? Are you part of a small team, or are you in a bloated, saturated org? Are you the go-to person when shit hits the fan, or are you a nobody people don’t talk to? Are you consistent, or are you vague and unpredictable? Does your work impact any relevant bottom lines, or are you just part of a cost centre? It really isn’t rocket science, for the most part.
It's really not that simple.
Numerous times I've seen promotions going to people who were visible but didn't do the actual work. Those who share the achievements on Slack, those who talk a lot, get to meetings with directors, those who try to present the work.
For the vast majority of people and cases, it really is that simple - but like I already said, "the process doesn’t have to be transparent, or consistent, or fair - in-fact it rarely is". There are exceptions to every rule, but for most people, it really does come down to some self reflection:
1. Do I consistently deliver more (in output, impact, or reliability) than peers at my pay level? 2. Is my work visible and tied to meaningful business outcomes, rather than low-impact tasks? 3. Am I known as dependable and easy to work with, especially under pressure? 4. Would the company feel a real loss-operationally or financially-if I left? 5. Have I made myself clearly more valuable to the organization than what I currently cost?
I promote people for simplicity
Bigger picture, when the thing you try to measure is subtle and difficult, you measure something obvious. That's what happening here.
Charlie Munger once said >>> Show me the incentive, I will show you the outcome
Problem is in big tech -- the incentives are all aligned towards complex stuff
you wanna get promoted - do complex stuff that doesn't make sense. If you get promoted, then it also boosts the performance of your manager.
the only way to escape this nonsense is to work at smaller companies
right now you've people advocating for A.I coded solutions yet never realizing that A.I solutions result in a convoluted mess since A.I never possesses the ART of software engineering i.e knowing what to cut out
It's not just that it looks good, there is constant pressure from other Engineers that we should "Do it right" and "Plan for the future" even if the future is murky and every design choice we take for scalability is probably just constraints that will hinder us if the requirements change.
as a manager its constant fighting the pressure to build "Great software" that is way above what the company needs instead building working software that addresses customer needs in a timely manner.
My dude we are s startup with two servers and 20 customers, we do not need infinite scalability.
I interviewed at a company that used a simple project to screen candidates. It was implementing a cash register checkout system. The task was soo simple that I couldn't figure out what they were looking for. So I implemented the simplest thing possible. I got the job partially because they were impressed by my utterly simple solution. I helped evaluate other candidates given the exact same problem and it's amazing how some people dialed up the complexity to 11. None of them passed the screening.
i think you can coach agents to build simple solutions in a simple way. I'm using amp rn so check back in 6 mo with me
Skill issue—in management.
Good leaders perceive workhorse vs showhorse spectrum, critical toil vs needless flash (and vice versa).
It’s hard. Most fail at hard things. The industry in the aggregate will fail at hard things
So you get articles like this.
Promotion Driven Development at its finest. There's no good way to fix this without better teams and less Lord of the Flies style management. Servant leadership helps here, but if your team is adversarial in nature there is no escape. A manager that needs an exciting story to get a feather in their hat will take the story every time over "+20 -8000" commit style developers. Your product will suffer accordingly.
A lot of this boils down to promo system being so systematized. I've never heard of people in any other field min/max their promotions as hard along with all of the expert jargon in any other field I've worked in. Packets, peers, comp, other co comps, what your boss thinks of you, what your boss thinks of your peers (nee: competitors), and the inevitable crash out when they don't get the promotion. All part of the bigco experience! I feel like when we systematized comp into ranks Lx, Ly we gave up our leverage a little bit.
Being able to solve problems with true simplicity is a master’s skill. The skill to recognize simplicity and its value is a skill as well.
You can try to explain this OP’s concept to a stakeholder in a 1000 different sensible ways and you’ll get blinking deer-in-headlight eyes back at you.
This skill is hard-earned and, so, rare.
Therefore, many hierarchies are built on sufficient mediocrity top to bottom.
Which works because bottom line doesn’t often matter in software dev anyway.
And even when it does matter it’s multiplicatively rare to have a hierarchy or even the market that it tries to serve who can build, comprehend, handle high power::complexity systems, products, tools.
that's why talking about the merits of simplicity is more of an art than something of utility to other engineers https://hammerproject.com/2023/07/28/complexity.html
it just isn't very appetising
I'm trying to sell simplicity to my target market, who I would call "semi-tech literate". Maybe it's stupid and I should sell whatever Forbes thinks is cool, but I just can't shake this feeling that I should be solving actual business problems.
We failed a bid for a project because of simplicity. We were to migrate a service running on an on-prem Kubernetes installation and a three, or five, node Apache Cassandra cluster to Azure.
The service saw maybe a few hundred transaction per day, total database size: 2 - 3GB. The systems would hold data about each transaction, until processed and then age it out over three months, making the database size fairly stable.
Talking to a developer advocate for Azure we learned that CosmosDB would get a Cassandra API and we got access to the preview. The client was presented with a solution were the service would run as a single container in Azure Websites and using CosmosDB as the database backend. The whole thing could run within the free tier at that point. Massive saving, much easier to manage. We got rejected because the solution didn't feel serious and to simplistic for an organisation of their scale.
On the other hand I also once replaced a BizzTalk server with 50 lines of C# and that was well received by the client, less so of my boss who now couldn't keep sending the bill for a "BizzTalk support contract" (which we honestly couldn't honour anyway).
2-3gb... an organisation of their scale :D
I sometimes feel like that's what it is. Simple solutions make some people feel unimportant.
If I was an engineering manager in an org which actually valued getting sh*t done - vs. bragging rights, head counts, and PHB politics - then I'd notice within a month that Engineer A (who the article has shipping in a couple days) got far more done then Engineer B (who needed 3 weeks).
And long before performance review time, I'd have mentioned further up that A was looking like a 5X engineer - best if we keep her happy.
This was already a post 6 hours ago which is now [dead].
What happened?
Not my experience.
I once hacked a spreadsheet in a week that was good enough to not embark on a multiple-months 3-devs project.
In the same team, I tweaked a configuration file for distributed calculations that shaved 2 minutes of calculation on an action that the user would run thirty times a day.
I got paid all right.
People don't give a shit about complexity or simplicity. They care about two things:
1. Does it work
2. How soon can you ship
There is a third thing that stakeholders really like: when you tell them what they should be building, or not building.