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.
Or just add a couple zeros to all the requirements until postgres is a worse solution than whatever the interviewer envisions. Isn't that the point of stating throughput requirements?
I'd assume that if he got a call from Patrick himself and a second opportunity to get interviewed, that's already a cue for interviewers to pass him regardless of what he says?
> 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.
I had this happen in a Google interview. I did back of the envelope math on data size and request volume and everything (4 million daily events, spread across a similar number of buckets) and very little was required beyond that to meet performance, reliability, and time/space complexity requirements. Most of the interview was the interviewer asking "what about" questions, me explaining how the simple design handled that, and the interviewer agreeing. I passed, but with "leans" vs. "strong" feedback.
If they don’t want to hear the correct answer, let them modify the question to exclude postgres answers. Interviews are a 2 way street, you will miss out on great candidates by being this stupid.
No, it was a perfectly fine question IMHO. it is a broken incentive - it is expected that you design complex systems regardless whether they are useful or not. Try to interview for the role you have to fill, nor for a role you a dreaming you would love to have whenever you're Google2.
If the interview wants you to think about stuff that never happens in your role, I think it is a sign that in your role, you're expected to solve the problems like in the interview.
I always find it funny that "engineers" straight out of school who barely know how to create a PR are expected to "ace" planet scale design questions. It's. Just. So. Dumb.
I would hire the "just use postgres" dude in a heartbeat without re-testing, if the numbers made sense, and perhaps give a stern talking-to to the interviewers. But then again I'm not a unicorn founder, so what do I know.
Eh, it's a good answer and shows good instincts, but they still want to know how he would design a system if one was necessary. There's no need to be ridiculous about any of this from either perspective, which is why it should never have been a "fail" without the original interviewer simply saying "That's a solid answer now tell me what you would do if you had to build something new". I mean look how much time he wasted for everyone including his own CEO by being stubborn about it.
In an interview you need to explain your thought process and demonstrate that you’re making an informed decision with supporting evidence.
Saying “just use Postgres” and then providing no explanation for why you believe Postgres is sufficient for the job, a general explanation of what type of hardware and architecture you’d use, and other details is not answering the question.
It's crazy the original interviewer allowed it to come to this which sounds like a waste of time for everyone involved, instead of simply saying; "Very good that is a legitimate solution to the problem. Now let's pretend you have to build something new, what would you do?"
Why on Earth did the company have to be so willingly obtuse and stupid about it including what sounds like the CEO (well at least he gave him another shot, but there doesn't need to be implicit assumptions about the "point of the interview", just come out and address it head on explicitly.)
I realized that my manager really confuses complexity with robustness. Case in point: we have a very complicated script that runs at deployment time to determine the address of the database. It's been the source of a few incidents - database wasn't discovered because it was restarting and the script passed an empty string instead of stopping the deployment, script failed because of python update and empty configuration was passed, shit like that. I've been arguing "bro why can't we make terraform create a config file with all the addresses that is directly passed to the app at deployment, or better yet, just copy-paste the database addresses into a file in the repo because we change something there once a year at maximum" but my manager took it as a sign of incompetence and my inability to understand complex systems.
I feel like lots of people just follow the happy path and don't understand that complexity incurs real cost.
> 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.
I actually really prefer your answer. I would likely counter with, “what potential issues could you see with doing things this way?” But a) you’ve shown me that you don’t charge into solutions without first attempting to define the problems, b) your follow-up answer reveals to me what kind of things you think are important, and c) I’d probably quickly ask something like,”let’s assume that in the past, we’ve had issues with missing changes when emailing this back and forth,” and encourage some more dialogue.
I do dislike interviews where a candidate can fail simply by not giving a specific, pre-canned answer. It suggests a work culture that is very top-down and one that isn’t particularly interested in actually getting to the truth.
Way back when I was in IT Admin, I used to have this problem all the time. Some non-tech person emails a spreadsheet, another non-tech person edits it, and saves it. The original person complains that they can't see the changes. Yeah, because it's saved in some MS Windows Profile location that no sane human would ever visit. My solution was to ONLY email links to shared files on a shared resource. The LAST thing I'd ever think of is writing software to solve this problem!
These days if I were interviewing someone and they said, "I'd use the simple solution that is fairly ubiquitous", I'd say, "yes! you've now saved yourself tons of engineering hours - and you've saved the company eng money".
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 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 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.
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.
That’s a terrible interview question. When I was helping with interview prep people would do post-mortems of their interviews and ask for advice. There were a lot of situations like yours where someone got sniped into arguing the merit of the question, sending the interview off the tracks.
Many just want to vent about bad interview questions and that’s fine, but the practical advice I gave was to remind yourself that some people write interview questions like word problems on a math exam; The specifics of the word problem are arbitrary and possibly illogical. You have to provide a solution and show your work because that’s the only part they care about.
This is most obvious when the questions are completely and obviously arbitrary, like “We need to print the number on each line, unless it’s divisible by 3 in which case we need to print ‘Fizz’…” (Although I have talked to people who got triggered into arguing the merit of FizzBuzz questions in an interview which, predictably, ended the interview early).
For questions like this I always advised that you assume it’s a word problem designed for the context of an interview. A good response would be “Well I would suggest Google Sheets because this is a solved problem! But if we assume we need a simple custom solution for other reasons I’d gather the requirements and propose a simple web form that captures…”.
Frustrating? Yes. But arguing the interview questions or trying to give shortcut responses that miss the point of word problems is only going to frustrate the interviewers.
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.
I think we'll see a decline of software as a product for this reason. If your job is to solve a problem, and you use AI to generate a tool that solves that problem, well then it's still your job to solve that problem regardless of which tool you use.
If you end up generating something that nobody understands, then when you quit and get a new job, somebody else will probably use your project as context for generating something that suits the way they want to solve that problem. Time will have passed, so the needs will have changed, they'll end up with something different. They'll also only partially understand it, but the gaps will be in different places this time around.
To be fair, a lot of the on call people being pulled in at 3am before LLMs existed didn't understand the systems they were supporting very well, either. This will definitely make it worse, though.
I think part of charting a safe career path now involves evaluating how strong any given org's culture of understanding the code and stack is. I definitely do not ever want to be in a position again where no one in the whole place knows how something works while the higher-ups are having a meltdown because something critical broke.
I wrote something similar in a Claude Code instructions.md: "minimize cyclomatic complexity" What happened next? It generated an 8 line wrapper function called only once from a different file. So, I told it to inline that logic in the caller. The result? One. Line. Of. Code.
So, I asked it to modify its instructions.md file to not repeat that mistake. The result was the new line "Avoid single-use wrapper functions; inline logic at the call site unless reused"
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.
This says more about you and the people you work with. I find engineers that have been at the company for a while are quite invaluable when it comes to this information, it's not just knowing the how but the when + why that's critical as well.
Acting like people can't be good at their job is frankly dehumanizing and says a lot about your mindset with how you view other fellow devs.
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.
Except that of course, the "simple" Door Desk was actually more expensive than the equivalent from Ikea, had no real additional functionality and took more time to put together. Which somewhat muddies the metaphor ...
I'm not sure I agree wit this, if I have work that needs to be done, and have a vague idea how long it should take
The engineer that consistently quotes 3x my expectation (and ends up taking 4x with bugs) is going to look way worse than the engineer that ships things quickly with no drama.
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.
It's easy to gloss over this assessment but ultimately this needs to be a key decision point for where you choose to work. No matter how well you manage complexity as an IC or a lower tier leader, if your upper tier of leaders don't value it, it won't last. Simplicity IME is not a "tail that wags the dog" concept. It's too easy to stomp out if nobody in power cares.
Yes, I should have added "...this way" because I meant that to address GP's claim of the metric-based numerical measurement.
In general, I agree that you can and should judge (not necessarily measure) thing like simplicity and good design. The problem is that business does want the "increased this by 80%, decreased that by 27%" stuff and simplicity does not yield itself to this approach.
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.
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.
I agree, it just sucks at understanding style and simplicity.
It's good at code generation, feature wise, it can scaffold and cobble together shit, but when it comes down to code structure, architecture, you essentially have to argue with it over what is better, and it just doesn't seem to get it, at which point it's better to just take the reins and do it yourself. If there's any code smells in your code already, it will just repeat them. Sometimes it will just output shit that's overtly confusing for no reason.
This is not entirely true. In an environment driven by business stakeholders, the engineer who ships features quickly, and that break rarely in production, will be greatly appreciated.
The engineer who takes weeks to over-engineer a simple feature, which then runs into unexpected side issues in production, much less so.
The environment where the over-engineer tends to be promoted is one where the engineering department is (too) far separated from where the end users are. Think of very large organizations with walled departments, or organizations where there simply is not enough to do so engineers start to build stuff to fight non existing issues.
This was my exact thought process reading this. The business side of my company does not care or want to wait for complex solutions that sound cool to engineers. If anything, we have the opposite problem: convincing business stakeholders when complexity is in fact warranted.
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.
Well, it depends what those requests are doing surely? I always thought it was weird to treat "request" as a unit of measurement. Are you requesting a static help page, or a GraphQL search query?
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.
This has been a thought theme throughout my career and have a good set of scenarios I never ended up publishing.
It's not just the most "elaborate system". The same thing happens in so many other ways. For example a good/simple solution is one and done. Whereas a complex one will be an interminable cause of indirect issued down the road. With the second engineer being the one fixing them.
Then there's another pattern of the 10x (not the case with all 10x-ers) seeding or asked to "fix" other projects, then moving on to the next, leaving all the debt to the team.
It's really an amazing dynamic that can be studied from a game theoretical perspective. It's perhaps one of the adjacent behaviors that support the Gervais principle.
It's also likely going to be over soon, now that AI is normalizing a lot of this work.
The problem can be complex, which sometimes means the solution needs to be complex. Often, you can solve a complex problem in simple ways. There’s many ways to do that:
a) finding a new theoretical frame that simplifies the space or solutions, helps people think through it in a principled way
b) finding ways to use existing abstractions, that others may not have been able to find
c) using non-technical levers, like working at the org/business/UX level to cut scope, simplify requirements,
The way you can make complexity work for your career, is to make it clear why the problem is complex, and then what you did to simplify the problem. If you just present a simple solution, no one will get it. It’s like “showing your work”.
In some orgs, this is hopeless, as they really do reward complexity of implementation.
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".
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.
> 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.
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".
> 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?
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?
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.
> 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.
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.
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?
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.
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.
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.
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.
Is it just me or could this apply to commentary as well? Sometimes, I set out to comment with all my thoughts and their intricacies related to the subject, but sometimes the simplest one contributes far more to the conversation. In my experience, simplicity enables others to more freely participate and contribute.
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).
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.
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.
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?
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.
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
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.
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.
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.
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.
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.
Or just add a couple zeros to all the requirements until postgres is a worse solution than whatever the interviewer envisions. Isn't that the point of stating throughput requirements?
> They made him do it again and he passed
I'd assume that if he got a call from Patrick himself and a second opportunity to get interviewed, that's already a cue for interviewers to pass him regardless of what he says?
This is the part I would say thank you, and pass on the opportunity.
And yes, I have done this on a second Google interview about 15 years ago.
> 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.
I had this happen in a Google interview. I did back of the envelope math on data size and request volume and everything (4 million daily events, spread across a similar number of buckets) and very little was required beyond that to meet performance, reliability, and time/space complexity requirements. Most of the interview was the interviewer asking "what about" questions, me explaining how the simple design handled that, and the interviewer agreeing. I passed, but with "leans" vs. "strong" feedback.
If they don’t want to hear the correct answer, let them modify the question to exclude postgres answers. Interviews are a 2 way street, you will miss out on great candidates by being this stupid.
> 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.
No, it was a perfectly fine question IMHO. it is a broken incentive - it is expected that you design complex systems regardless whether they are useful or not. Try to interview for the role you have to fill, nor for a role you a dreaming you would love to have whenever you're Google2.
If the interview wants you to think about stuff that never happens in your role, I think it is a sign that in your role, you're expected to solve the problems like in the interview.
Sorry, I didn't get it. What was the 'right' answer?
distributed virtual abstract factory
I always find it funny that "engineers" straight out of school who barely know how to create a PR are expected to "ace" planet scale design questions. It's. Just. So. Dumb.
> They made him do it again and he passed.
I would hire the "just use postgres" dude in a heartbeat without re-testing, if the numbers made sense, and perhaps give a stern talking-to to the interviewers. But then again I'm not a unicorn founder, so what do I know.
Eh, it's a good answer and shows good instincts, but they still want to know how he would design a system if one was necessary. There's no need to be ridiculous about any of this from either perspective, which is why it should never have been a "fail" without the original interviewer simply saying "That's a solid answer now tell me what you would do if you had to build something new". I mean look how much time he wasted for everyone including his own CEO by being stubborn about it.
> 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.
In an interview you need to explain your thought process and demonstrate that you’re making an informed decision with supporting evidence.
Saying “just use Postgres” and then providing no explanation for why you believe Postgres is sufficient for the job, a general explanation of what type of hardware and architecture you’d use, and other details is not answering the question.
The point isnt to give a simple answer, even if it's a correct answer. The point is show how much you know and how smart you are.
The question is framed to you as a way for you to show you know x, y and z and talk about x, y and z.
Even if a valid solution is just do a, that's great. But the interviewer has no idea if you actually know about x ,y and z do they ?
It's crazy the original interviewer allowed it to come to this which sounds like a waste of time for everyone involved, instead of simply saying; "Very good that is a legitimate solution to the problem. Now let's pretend you have to build something new, what would you do?"
Why on Earth did the company have to be so willingly obtuse and stupid about it including what sounds like the CEO (well at least he gave him another shot, but there doesn't need to be implicit assumptions about the "point of the interview", just come out and address it head on explicitly.)
I realized that my manager really confuses complexity with robustness. Case in point: we have a very complicated script that runs at deployment time to determine the address of the database. It's been the source of a few incidents - database wasn't discovered because it was restarting and the script passed an empty string instead of stopping the deployment, script failed because of python update and empty configuration was passed, shit like that. I've been arguing "bro why can't we make terraform create a config file with all the addresses that is directly passed to the app at deployment, or better yet, just copy-paste the database addresses into a file in the repo because we change something there once a year at maximum" but my manager took it as a sign of incompetence and my inability to understand complex systems.
I feel like lots of people just follow the happy path and don't understand that complexity incurs real cost.
> 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.
I actually really prefer your answer. I would likely counter with, “what potential issues could you see with doing things this way?” But a) you’ve shown me that you don’t charge into solutions without first attempting to define the problems, b) your follow-up answer reveals to me what kind of things you think are important, and c) I’d probably quickly ask something like,”let’s assume that in the past, we’ve had issues with missing changes when emailing this back and forth,” and encourage some more dialogue.
I do dislike interviews where a candidate can fail simply by not giving a specific, pre-canned answer. It suggests a work culture that is very top-down and one that isn’t particularly interested in actually getting to the truth.
In our agency that would be a plus, because we focus on customising existing products instead of building everything from scratch.
Exactly because that means less costs for software development when deliverying solutions.
Way back when I was in IT Admin, I used to have this problem all the time. Some non-tech person emails a spreadsheet, another non-tech person edits it, and saves it. The original person complains that they can't see the changes. Yeah, because it's saved in some MS Windows Profile location that no sane human would ever visit. My solution was to ONLY email links to shared files on a shared resource. The LAST thing I'd ever think of is writing software to solve this problem!
These days if I were interviewing someone and they said, "I'd use the simple solution that is fairly ubiquitous", I'd say, "yes! you've now saved yourself tons of engineering hours - and you've saved the company eng money".
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.
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 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 would ask, why are they emailing it? Maybe there's a good reason they can't use sheets.
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.
That’s a terrible interview question. When I was helping with interview prep people would do post-mortems of their interviews and ask for advice. There were a lot of situations like yours where someone got sniped into arguing the merit of the question, sending the interview off the tracks.
Many just want to vent about bad interview questions and that’s fine, but the practical advice I gave was to remind yourself that some people write interview questions like word problems on a math exam; The specifics of the word problem are arbitrary and possibly illogical. You have to provide a solution and show your work because that’s the only part they care about.
This is most obvious when the questions are completely and obviously arbitrary, like “We need to print the number on each line, unless it’s divisible by 3 in which case we need to print ‘Fizz’…” (Although I have talked to people who got triggered into arguing the merit of FizzBuzz questions in an interview which, predictably, ended the interview early).
For questions like this I always advised that you assume it’s a word problem designed for the context of an interview. A good response would be “Well I would suggest Google Sheets because this is a solved problem! But if we assume we need a simple custom solution for other reasons I’d gather the requirements and propose a simple web form that captures…”.
Frustrating? Yes. But arguing the interview questions or trying to give shortcut responses that miss the point of word problems is only going to frustrate the interviewers.
The lesson was that sometimes the interviewee can be more competent than the interviewer and they should run.
So nobody can ever hire someone better at particular skills than they are? Oh boy.
Or maybe this: https://news.ycombinator.com/item?id=47247719
I had a similar idea once when answering a Stack Overflow question[0].
[0] https://stackoverflow.com/a/1831841/61938
Quoting your comment: "You definitely don't want to hire the person who thinks - bizarrely - that using library functions is a sign of weakness."
So true...I've failed interviews, because the interviewee did see using library functions as a sign of weakness.
Remember you're interviewing them just as much as they are interviewing you.
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.
I think we'll see a decline of software as a product for this reason. If your job is to solve a problem, and you use AI to generate a tool that solves that problem, well then it's still your job to solve that problem regardless of which tool you use.
If you end up generating something that nobody understands, then when you quit and get a new job, somebody else will probably use your project as context for generating something that suits the way they want to solve that problem. Time will have passed, so the needs will have changed, they'll end up with something different. They'll also only partially understand it, but the gaps will be in different places this time around.
> now nobody fully understands what was generated
To be fair, a lot of the on call people being pulled in at 3am before LLMs existed didn't understand the systems they were supporting very well, either. This will definitely make it worse, though.
I think part of charting a safe career path now involves evaluating how strong any given org's culture of understanding the code and stack is. I definitely do not ever want to be in a position again where no one in the whole place knows how something works while the higher-ups are having a meltdown because something critical broke.
The "coding benchmarks" should be based heavily biased on what dependencies they use etc. Reduced characters etc.
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
I wrote something similar in a Claude Code instructions.md: "minimize cyclomatic complexity" What happened next? It generated an 8 line wrapper function called only once from a different file. So, I told it to inline that logic in the caller. The result? One. Line. Of. Code.
So, I asked it to modify its instructions.md file to not repeat that mistake. The result was the new line "Avoid single-use wrapper functions; inline logic at the call site unless reused"
instruction.md is the new intern.
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
This says more about you and the people you work with. I find engineers that have been at the company for a while are quite invaluable when it comes to this information, it's not just knowing the how but the when + why that's critical as well.
Acting like people can't be good at their job is frankly dehumanizing and says a lot about your mindset with how you view other fellow devs.
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"
What is the maintenance cost when Opus 6 or whatever is available?
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.
Except that of course, the "simple" Door Desk was actually more expensive than the equivalent from Ikea, had no real additional functionality and took more time to put together. Which somewhat muddies the metaphor ...
(amzn 94-96)
I'm not sure I agree wit this, if I have work that needs to be done, and have a vague idea how long it should take
The engineer that consistently quotes 3x my expectation (and ends up taking 4x with bugs) is going to look way worse than the engineer that ships things quickly with no drama.
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.
It's easy to gloss over this assessment but ultimately this needs to be a key decision point for where you choose to work. No matter how well you manage complexity as an IC or a lower tier leader, if your upper tier of leaders don't value it, it won't last. Simplicity IME is not a "tail that wags the dog" concept. It's too easy to stomp out if nobody in power cares.
Yes, I should have added "...this way" because I meant that to address GP's claim of the metric-based numerical measurement.
In general, I agree that you can and should judge (not necessarily measure) thing like simplicity and good design. The problem is that business does want the "increased this by 80%, decreased that by 27%" stuff and simplicity does not yield itself to this approach.
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.
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.
I agree, it just sucks at understanding style and simplicity.
It's good at code generation, feature wise, it can scaffold and cobble together shit, but when it comes down to code structure, architecture, you essentially have to argue with it over what is better, and it just doesn't seem to get it, at which point it's better to just take the reins and do it yourself. If there's any code smells in your code already, it will just repeat them. Sometimes it will just output shit that's overtly confusing for no reason.
What about someone inexperienced but skeptical, using AI to learn + fix their own code before opening the PR?
This is not entirely true. In an environment driven by business stakeholders, the engineer who ships features quickly, and that break rarely in production, will be greatly appreciated. The engineer who takes weeks to over-engineer a simple feature, which then runs into unexpected side issues in production, much less so.
The environment where the over-engineer tends to be promoted is one where the engineering department is (too) far separated from where the end users are. Think of very large organizations with walled departments, or organizations where there simply is not enough to do so engineers start to build stuff to fight non existing issues.
This was my exact thought process reading this. The business side of my company does not care or want to wait for complex solutions that sound cool to engineers. If anything, we have the opposite problem: convincing business stakeholders when complexity is in fact warranted.
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.
Well, it depends what those requests are doing surely? I always thought it was weird to treat "request" as a unit of measurement. Are you requesting a static help page, or a GraphQL search query?
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
This has been a thought theme throughout my career and have a good set of scenarios I never ended up publishing.
It's not just the most "elaborate system". The same thing happens in so many other ways. For example a good/simple solution is one and done. Whereas a complex one will be an interminable cause of indirect issued down the road. With the second engineer being the one fixing them.
Then there's another pattern of the 10x (not the case with all 10x-ers) seeding or asked to "fix" other projects, then moving on to the next, leaving all the debt to the team.
It's really an amazing dynamic that can be studied from a game theoretical perspective. It's perhaps one of the adjacent behaviors that support the Gervais principle.
It's also likely going to be over soon, now that AI is normalizing a lot of this work.
The problem can be complex, which sometimes means the solution needs to be complex. Often, you can solve a complex problem in simple ways. There’s many ways to do that:
a) finding a new theoretical frame that simplifies the space or solutions, helps people think through it in a principled way
b) finding ways to use existing abstractions, that others may not have been able to find
c) using non-technical levers, like working at the org/business/UX level to cut scope, simplify requirements,
The way you can make complexity work for your career, is to make it clear why the problem is complex, and then what you did to simplify the problem. If you just present a simple solution, no one will get it. It’s like “showing your work”.
In some orgs, this is hopeless, as they really do reward complexity of implementation.
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.
If you're at a place that rewards complexity, you might be able to pitch simplicity as something that to get right, requires deep understanding of complex information theoretic concepts and deep understanding of ontological knowledge about the domain (it helps that this is true https://benoitessiambre.com/simple.html ). You can talk about the Bayesian Occam's Razor ( https://benoitessiambre.com/abstract.html ) and about minimizing the entropy of code ( https://benoitessiambre.com/entropy.html ), of tests ( https://benoitessiambre.com/integration.html ) and even of infrastructure ( https://benoitessiambre.com/pgcentrism.html ).
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.
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.
> 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.
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".
> 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?
"The Parable of the Two Programmers" by Neil W. Rickert is pretty much about this, from the year 1985...
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?
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
Shipping a button in 2026… <https://www.youtube.com/watch?v=xE9W9Ghe4Jk>
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.
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.
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?
Related: https://news.ycombinator.com/item?id=47242765
That is dead, but I vouched for it.
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.
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.
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.
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.
Is it just me or could this apply to commentary as well? Sometimes, I set out to comment with all my thoughts and their intricacies related to the subject, but sometimes the simplest one contributes far more to the conversation. In my experience, simplicity enables others to more freely participate and contribute.
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).
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
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.
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.
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.
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?
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.
Posted just yesterday: https://news.ycombinator.com/item?id=47242765
Bigger picture, when the thing you try to measure is subtle and difficult, you measure something obvious. That's what happening here.
Steve Jobs
I promote people for simplicity
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
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
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.
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.
what a pub/sub hater
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
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.
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.