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.
Having been both the interviewer and the candidate in this kind of situation, this is really a big interviewer training failure.
The general way to handle this as an interviewer is really simple: acknowledge that the interviewee gave a good answer, but ask that for the purposes of evaluating their technical design skills that you'd like for them to design a new system/code a new implementation to solve this problem.
If the candidate isn't willing to suspend disbelief for the exercise, then you can consider that alongside all of the other signals your interviewer team gets about the candidate. I generally take it as a negative signal, not because I need conformance, but because I need someone who can work through honest technical disagreements.
As a candidate, what's worked for me before was to ask the interviewer if they'd prefer that I pretend ____ doesn't exist and come up with a new design, but it makes me question whether I want to join that team. IMO it's the systems design equivalent of the interviewer arguing with you about your valid algorithm because it's not the one the interviewer expects.
A good interviewer won’t be looking for a single solution to the problem. I’d expect them to entertain the Google Sheets answer - it’s good signal that the candidate will consider what already exists in the world. I’d rather extend the problem: the team is spending considerable time iterating with manual entry, what would you do?
"That does sound like something nice to have. However, recreating Google Sheets is a substantial undertaking. First, we need to evaluate the business case for duplicating something that already exists to ensure that there is a net benefit in doing so. Second, we need to determine if the business has sufficient capital to see the project through."
I suspect a lot of businesses are going to make this mistake in the "SaaS is dead" era as companies try to eliminate $50k/mo subscriptions for boring business software, and they figure it's easier to burn AI tokens creating an internal solution they didn't plan on maintaining in the far future.
"Well I would probably go home and work on my resume because that's a fool's errand."
I hate going to work and reinventing wheels all day because the company I work for thinks it's so special that every business function needs a 100% tailored solution to solved problems. I much prefer working somewhere that's able to tailor business processes to conform to existing standards.
I’ve interviewed a few hundred people. Probably approaching a thousand, if not already. An interview is a scenario, and if you aren’t willing to engage in the scenario that we all agreed to partake in, that’s a huge warning sign that you’re going to be difficult later down the line. The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I'd call it an interviewer failure, not an interviewee failure.
I absolutely want people I hire to be "difficult" when the moment calls for it. If the scenario is one where the right business/user choice is "let them keep using Google Sheets", then the answer I want is "Google Sheets seems fine to me", no matter what people with more power start out wanting. Too many developers have been encouraged to be minions, not professionals.
Ditto for ones who act like everything is a nail for their coding hammer. A developer who can save a company a couple hundred thousand dollars by not turning something simple into a big coding project is a rare and precious commodity. Or should be, at least.
The thing to do isn't to give demerits for "being difficult". The thing to do is to then add something to the scenario where they get into the thing you want them to get to. "For this, we need better access control than Google Sheets allows us." Or, "We need this to be more closely integrated with our accounting system."
Unless, of course, what you're hiring for is the willingness to roll over for unreasonable requests from people with more power. Which, honestly, a lot of places are.
but also maybe its a green flag in that this employee might see the wood for the trees and save the company a lot of money later down the line. In my experience, a lot of engineers can waste a lot of time dicking around re-inventing wheels and whatnot.
While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate [0].
For reference, I think both answers are fine and both perspectives (its a positive or a negative) are equally valid. Its just that I don't think we can confidently state either way.
> While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate
Yes, I did. More than once. I always regretted it. Sure it could be a cognitive bias, but the entire interview process is essentially trying to figure out “can I work with this person”.
> I think both answers are fine and both perspectives are equally valid
I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
and if you hire only based on solely on employee compliance then you are also probably missing the wood for the trees. I've worked in such orgs and they're extremely vulnerable to cargo culting.
I’m not hiring on compliance. I’ve accepted that his answer is correct but asked for the purposes of the exercise if he can put that to a side so we can talk about it. I’ve worked with and hired people like this and they tend to turn every molehill into a mountain, which is just killer on a small team.
I think you missed the point in GP's post. Not all organizations optimize for problem solving. Some organizations prefer subordinates who follow orders (or better, is able to read the mind of the boss to decipher what order he is actually making) than those who breaks out of the box and says ”just use gsuite, boss."
sure but if its not a privately held business then using gsuite is better for the shareholders. Ultimately its the bosses choice, but for the board to fire them its worth knowing they were aware of being able to use gsuite instead of pissing away resource on a needless project.
Most real-world scenarios aren't so arbitrary, and hardly any have a "right answer". If I had a candidate that broke out of the box of our interview to give a good answer, and that's not the answer I "want", I'd be more likely to believe the interview question is the problem, not the candidate.
remember that we already did the "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?" part.
the "good answer" was already acknowledged, the "real-world scenario" answer was accepted.
the second part ("what if we wanted to build it in-house") is purely hypothetical to gauge how the interviewee would approach the specific technical challenge. if they again say "well that is dumb i would just use sheets", that is absolutely an interviewee problem.
> The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I think a lot of people miss this point.
Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.
Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.
In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).
I think the contrived scenarios you come up with need to not have a trivial solution. Everything about my brain is optimized for KISS, it breaks everything to turn down simple solutions to reach for something more complex.
Think of it this way: they're paying you lots of money to build something boring that has a lot of prior art/research available to you for free. This could be the easiest money maker in your life.
It's not your problem they're hellbent on building a new wheel. They're willing to pay you!
Chances are, you've thought of your own pain points in whatever they've asked you to build and you've now got an opportunity to shine by solving them and demonstrate your expertise.
There is a tool invented lately, that's very good for solving problems, that are well-researched and had been solved multiple times already.
This tool is actually why there is a RAM shortage in the world right now.
Some even say, this tool will replace a lot of workers soon(sic!).
While I agree, how much training does anyone get as an interviewer? I spent 10+ years doing interviews at all sorts of orgs (including Fortune 500s, government, etc.) without a single hour of interviewer training.
Now that I think about it, none of those organizations ever trained me at anything at all. Huh.
> none of those organizations ever trained me at anything at all
They trained us repeatedly not to bribe foreign government officials, even though I had zero access to anybody like that. There was also some mandatory training against harassing coworkers. I.e. "protect the company from lawsuits" training, not "here are some ideas for how to do your job more effectively" training. They were megacorps, too.
Yeah that's proven by the fact they get degree educated level engineers and force feed them videos designed for people working entry level positions. Its a crying shame because there's actually a lot of interesting discussions around nuance that are just sidelined by these videos creating basic bitch absurdities:
> During the lunch break, Jim has dipped his penis into Samantha's yoghurt
> is this:
> a) entirely acceptable, its just his culture
> b) a borderline issue
> c) something that someone should report to HR
Instead of:
Jane is developing feelings for someone that reports to her, they meet up outside of work and have a one-night stand. What should Jane do next?
That's unusual. Maybe that's a US thing? In Europe anywhere I've had to interview people I've received at least a couple of hours of training and then usually sat in as the shadow on at least one interview.
Quality varies, but I think it's only the super small outfits where I've been expected to just wing it.
> While I agree, how much training does anyone get as an interviewer?
TL;DR: not enough training.
As a hiring manager, whenever we start a hiring period I have a conversation with my interviewer team about what qualities we're looking for and review the questions they plan to ask in order to normalize the process. Stuff like "what does a good answer look like, and why? what does a bad answer look like? is this something easy for a candidate to engage with or will you spend half the interview just explaining the background? is this coding question unreasonably hard?" and so on.
I also look at the evaluations that interviewers give relative to other interviewers. Almost every hiring cycle I've done I've had to deal with some interviewer (all over the seniority spectrum) asking unreasonably hard questions.
Yeah, I had no training on being an interviewer before I started doing interviews. My manager gave me some tips, and I came up with two security bug-hunt exercises (was hiring AppSec engineers), but that was it.
Now, I wonder if I had rejected earlier candidates that I would have passed if I was a better interviewer.
The best advice I've had on interviewing is: Find an actual problem that your team is actually working through and ask the candidate how they would approach it.
Then to jazz it up: simplify the proble. To get to the root stuff that needs to be covered (e.g. ignore creating Jira tickets and focus on connecting to a database with cross-refion replication).
You also want it to be simple enough that it can be solved in <30 minutes
Seriously? I worked at startups and research institutions. We trained people on interviews. I know Google used to invest quite a bit on interview training.
Sounds common to have training in big tech but I never received any training either. Sometimes we’d discuss changes we wanted to make to the interview process, which suppose could be considered adjacent to training.
I prefer pushing the constraints to motivate a different solution instead of asking them to do an unmotivated exercise.
“Google Sheets is a great solution for two people, but let’s say the department expands and now it’s ten people. How does this change your answer?”
It’s easy to break Google Sheets as a workflow by increasing the number of users, adding complex business logic, etc.
It’s interesting to see what candidates come up with and how they think. Sometimes the solutions are genuinely interesting. Mostly they’re not, which is okay. If you don’t give yourself the opportunity to learn as an interviewer, you’re missing out.
It takes a lot of practice to become good interviewer and majority of ICs especially at small shops never get the required mileage. I don't think i really knew what i was doing until like 100 sessions in...
Thats fair, it definitely sucks for those seeking employment to have a really awful interview. How do you turn it around without looking like an a-hole…
At google where i started interviewing it worked pretty well at least initially when recruiters assembled panels such that you only get 1-2 inexperienced interviewers out of 6. They also didn’t let you do screens as fresh interviewer where it’s much harder to get signal. Every other place i worked it was basically a crapshoot
If I would be the interviewer in this kind of situation, I would just follow up with something like this: "that might be a good option, but let's assume you need to build a tool to replace those excel sheets, ..."
Surprisingly often you do get an interviewee who just won't accept the premise of the hypothetical. I've had people get hung up on the equivalent of 'but I'd just use excel' even with prompting/nudging/explanation that this is an exercise.
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
Maybe 10 years ago I interviewed both for Netflix and Facebook.
At Netflix, I used a state machine library to handle the project they gave me. Got rejected because I didn't show I knew raw JavaScript enough.
At Facebook, I wrote a calendar dropdown from scratch. Got rejected because I should have used a library.
Interviews sometimes is just a lottery...
Yes I know both companies should have set the expectation, but you can set the expectation for EVERYTHING, otherwise you give candidates all the answers you're expecting. There's always going to be some chaos due to the huge number of variables.
As a hiring manager I've had situations like this arise because there was a gap in my plan and I didn't realize it. When those come up, we thank them for their cleverness, apologize to the candidate, reframe the situation, and give them another shot.
But also sometimes I leave intentional ambiguity in the plan. Part of the goal is to see if they have a degree of common sense commensurate to their level. If they're interviewing for a high level position, I'd expect them to be able to spot silly flaws and push back that perhaps the whole problem needs rethinking. And of course, I also expect them to know the brute force solution as well. Do they only know one? Both? Let's fine out.
Postgres might have been a perfect answer, but the candidate needs to explain why and how.
The purpose of the interview is for the candidate to demonstrate their thought process and ability to communicate it. “Just use Postgres” doesn’t do that.
This would be more obvious if it was a LeetCode problem and the candidate just regurgitated an algorithm from memory without explaining anything about it. Yeah it’s technically the right answer but the interviewer can’t tell if you actually understand what you’re talking about or if you just happened to memorize and answer that works.
Interviews are about communication and demonstrating thought process.
100% interviews are about communication and demonstrating thought process; after going through some rounds of interviewing candidates myself, any candidate who can adequately explain what they're thinking and how they arrive at their conclusions will be able to demonstrate their skills much more thoroughly than 'just use Postgres'.
That being said, it's also on the ones giving the interviews to push the candidates and ensure that they really are receiving the applicants best. The interviewers don't want to miss potentially great candidates (interviews are hard and nerve-wracking, and engineers aren't known for their social performance), and thus sometimes need to help nudge the candidates in the right direction.
Fully agreed on the point that interviewers should prompt and push candidates in the right direction.
The best thing someone can do to learn how to perform well in interviews is to sit on the other side where you’re interviewing candidates. Some candidates will get stuck on arguing some irrelevant point or trying to fight against the interview question for too long in an interview. Once you see how much it hurts the interview process you learn to never do it yourself.
I went to law school and a few of us students were engineers. For our first set of essay exams, the professors all instructed us to "just answer the legal question" and not include extra analysis. After the exam, many of the engineers didn't do well because the professors *actually* wanted you to weave the whole sylabus into your answer (i.e., discuss hypotheticals that were not actually part of the question asked), not just answer the question. After that, we were fine.
This is also what I learned the hard way. In many situations the customer doesn’t say what they really want. There are a lot of reasons why. I usually have to write down a lot of hypotheticals. If X is the primary concern, we should do Y. If U is the issue, we should do V.
I wouldn't expect customers to say what they really want. They are looking for faster horses after all. But law professors? Among all professors, law professors should be the ones saying what they really want.
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?
Right? I'll often structure interview questions like this. I give a basic problem, hoping for a basic answer. Then I add complexity, seeing how they respond.
In my experience, it's much easier to train somebody on how to scale a basic system up in response to need than it is to get somebody who favors complexity to cut it back.
> neurodivergent people in our ecosystem who would trip up on that question just because of how it's framed
If anything, it's neurodivergent interviewers. If I insisted on a different design I'd either ask a question that's not solved by "just use postgres" or follow up with "ok, that would work, but what if <something that would prevent postgres from working>". Just failing a candidate for a correct answer is a prime example of why interviewing is so bad.
It's probably more about your mindset, than about being neurodivergent vs. neurotypical. If you care more about maintainability and operations, there's a whole host of solutions you'd never built.
if your brain short-circuits at ambiguity, or you're completely incapable of understanding intent and you take everything literally, that is a negative hiring signal.
> 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.
To be fair, the simple answer is not so simple within Google.
The issue is that Google achieves reliability by insisting on n+2/n+1. Globally your service is in at least 2 more data centers than is required for full load. In each region in at least 1 more data center than is required for full load.
If you're using the Google toolchain, all of the scalability and fallover problems are automatically handled by the layers that you're relying on. Which everyone expects you to use, because they are already integrated into the environment.
But if you go to use Postgres as a data storage layer, then you also need to take care of replication, failover, backup, and make sure that this is integrated with the automated systems that Google already has to detect when this is needed. Even after you've done that, people from outside of your team will need to be convinced that you've done that. Simply because you're doing things differently, you'll get extra scrutiny.
As a result, even if Postgres would have worked perfectly well, it is usually not the optimal answer for someone who is working within Google's environment. Don't think of it in terms of, "Does this do the job?" Think about it in terms of, "Can those in the broader organization easily certify that this does the job?" That certification is easier when you use standardized parts that are themselves already certified within the organization.
My guess is that your interviewer was aware of this. And was left with, "What about that question that I didn't think to ask you about?"
If you're interviewing at Google, the expected answer to the interview question can't be to use Google's internal tools. "Use Postgres" is the standardized, understandable answer for anyone outside Google who needs to solve Postgres-shaped and Postgres-sized problems.
FWIW, that was the second time I interviewed at Google. The first time, which resulted in strong yes across the board at L7, the first system design was to design Youtube Video Upload. The second was a more practical problem about replacing a high-volume logging component where correctness was critical but environment was space-constrained (i.e. no ability to run old + new in parallel).
Those were my favorite system design rounds ever, thanks to the problems being interesting and the interviewers also being very dynamic. It was also pre-Covid, so it was just awesome whiteboard design sessions.
This is just an indication that it's a poor interviewing technique. If you ask a question expecting the answer to be predictable then you had better cover all possible ambiguity in leading the candidate to the answer you want to hear. But then you're no longer asking the candidate to be creative, are you? As an interviewer I might be more inclined to allow such an answer and then follow up with questions of my own to test the limits of the candidate's knowledge of and confidence in Postgres as a technical choice for serving all the different constraints of the problem space. This way either I discover how well-reasoned the answer is or else (for a good candidate) it prompts them to adjust the design to better fit the problem. In no case would I expect they need to fit their answer into some key and then scold them for not playing along with my imaginary game.
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.
On the one hand, interviewers can suck. They can be uninterested in understanding and embrace instead the role of a trigger-happy interrogator looking not for a good response - something that may very well require effort and considering new ideas on the part of the interviewer - but an excuse to cross you off the list. The interview begins to look like a game of "Guess what I'm thinking". Interviews should simulate a colleague asking you for help.
On the other hand, interviewees can give poor answers with no explanation. The interviewer should press for an explanation in those cases, of course, but perhaps some are trying to see if the interviewee instinctively provides at least some basic rationale behind the answer without having to be prodded each time, in which case it is a matter of communication habits and skills. Communication is essential, and it is under-emphasized and under-taught in so-called 'STEM' curricula.
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?
> yes you might be right but you also understand what the point of the interview is
To make the interviewer feel smart and powerful? To hire people who will do the thing the boss wants whether or not it makes sense? To find people who will overdesign things to maximize resume impact and the ability of their bosses to talk about what sophisticated systems they're running and for which they therefore need a much bigger budget?
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.
Great example, and a lost opportunity in the interview---they should have asked "What are the requirements that would invalidate this answer? and what would you design if the requirements were changed in this way?". Maybe even "how long is the runway for your Progress solution if we consider future scaling up of the requirements"
Sometimes you just have a bad interviewer who is looking for something specific from you but isn't telling you. If you're experienced in these interviews, you catch the signs and adapt by asking questions to suss out which direction the interviewer wants to take it.
Sometimes your answer is plausible but the interviewer wants to see you justify it. Sometimes your answer is wrong but the interviewer wants to see if you can reason your way through it, and maybe come up with an alternative.
If you're junior/inexperienced, it's often hard to tell and it'll feel arbitrary/unfair, and unfortunately that's just how it goes. As a more senior/experienced candidate, you can often figure out which situation you're in by asking questions to feel out the interviewer and then try to pivot during the interview, though it still takes valuable minutes out of the interview that you could have otherwise spent showing your competence.
Completely idiotic on the part of the interviewer. Failing somebody for a correct answer - what a waste of everybody's time. If you want the candidate to pursue a particular technical path, tell them to do so while they're there in the office.
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.
The question was bad if using Postgres would really be a better solution than designing and implementing a bespoke system, under the stated constraints. Either they should provide a better problem statement, or at least immediately follow up with “okay, suppose you can’t make use of an existing system like Postgres for $reasons”.
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.
If the numbers can be satisfied by a Postgres then thats the correct answer. The interviewers fucked up, because they sized the problem wrongly.
This is the same issue that was prevalent when the industry switched from HDD to SSD: some system design questions suddenly became trivial, because the IOPS went up by magnitudes. This is not a failure of the interviewees, who correctly went with the times, but a failure of the interviewers.
And people weeded out by this kind of questions are probably rightfully so. I for one could not ever work with someone that says "my answer is correct, period.". Part of the answer and the discussions made by mature individuals must ask for feedback, incorporate it in your design, be open to compromises sometimes but also to die on a hill when it makes sense. And in an interview context, you ought to show the hiring manager all these faces.
Then, there are hiring managers that suck and you might be discarded because you didn't follow the script. Sure, but that's a bullet you dodged.
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.
The point is the interviewers are sometimes obtuse.
Sometimes the point of the interview is to see if the candidate knows an existing solution and "just use postgres" is the good answer. Sometimes it's to test the technical chops and pretending postgres doesn't exist is the point.
The candidate shouldn't be expected to always guess right, unless the position says "a psychic". The interviewer should notice if the candidate is solving the wrong kind of problem and nudge them in the right direction instead of punishing the candidate for the wrong guess.
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 best way to get promoted at stripe is just self-marketing and social manipulation. Good engineers are leaving meanwhile tecnical leadership is being replaced with designers and marketers. Internal performance metrics are heavily manipulated as well. Patrick has completely surrounded himself with extreme sycophants at this point - he has no idea what is actually going on in his company beyond curated metrics produced by manipulative sociopaths.
Patrick Collison sounds like a lovely, trusting, scientifically-minded man who needs to learn the constructive power of destruction. The power of rage and contempt for bad solutions and bad communication (regardless of intent).
With a smiley face front-end, of course. Wouldn't want to seem not-nice!
Agreed, I really like Patrick - he is smart, humble, hardworking and trusting. But his kind and trusting nature is being aggressively exploited by some truly despicable people.
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.
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.)
“There’s no right answer we just want to see how you think” is gaslighting if there is a right answer and wrong answer.
This should go straight to the DOL, EEOC, FTC and other bodies as some form of abusive labor practice that excises it from the employment process under threat of economic sanctions
I remember getting a test, in an interview in the 1990s, where I was asked to design a set of gates (ICs) to do some binary maths (Division, multiplication, etc). The input was an 8-bit set of leads, and the output was an 8-bit set of leads.
I looked at the formula, and drew two wires, connecting a couple of the leads from the input, to the output.
Ha! I just had a debate about this with my friend. A certain ferry company uses a big Google Sheet to track where all of its vessels are currently docked in their home port, as well as which employee is assigned to which vessel for the day, etc (it's very information dense with color coding, and employees check it daily to get their vessel assignment). My friend thought this was completely unacceptable for a big company, and that they should build a bespoke software for this purpose. I think that it was a brilliant idea to use Google Sheets, it already solves all of the difficult problems and obviates the need to have an inhouse software development team or an expensive contract. I buried my hubris deep underground
As a teenager I worked at a company that rented rafts for a short trip down a river. We’d take the rafts from the customers at the end and truck them back up to the start. As they became bigger and busier, it became more important to keep track of the status of rafts and know when they were going to be getting back to the top.
They paid tens of thousands to have software made for this purpose. It sucked and was totally unable to handle the simultaneous realtime access and modification that was required.
They knew I was good with computers, so asked me if I had any ideas. In about an hour I made them a Google Sheet that worked great for the next several years until I left.
I've just spent a few weeks making a tool in our software to replace a complicated google sheet, and it was surprisingly hard. I think the most important thing was that our designer really figured out what the tool should do. If we've just replicated what they have and made a columnar editor of sorts, we would've just made a less flexible tool for them. But in the end, we made something not even resembling what they had, but which actually solved the core issue, and I think that's important.
And when you take away their sheet, you better be ready to support them. If they need to track new data, they could just add a new column in their sheet. Now they have to talk with tech. If tech blocks operations, they're quickly back to their sheets. The tool made by tech should be an enabler, not something to force compliance or whatever.
Sheets are so, so flexible. This can be really hard to replace. At the same time, they're also brittle with little system support. Like the example above, what if you assign someone not working that day to a boat? Or accidentally put two boats in the same location? Lots of small issues that proper tooling could handle, especially when backed with more data inside the system.
What made the operators happy to use my tool in the end was that they didn't have to punch so many numbers. They would copy paste numbers from various systems into their sheet every hour to keep track. The tooling pulls it in real-time.
So we replaced this one sheet, because it would help them a lot. But their other sheets we're leaving untouched for now. Nothing to gain by moving them. So judge each sheet individually.
My startup used Google Sheets as a CRM until we discovered there’s a 3 million row limit (by running into it) and had to build something else. Sheets is amazing. Don’t forget to lock that first header row, though.
I'm there with you... maybe, maybe using the sheets API to create a simpler front end for very specific use cases, like an individual seeing their assignment for the day, or maybe texting everyone that info.
As much as people will rely on databse (rdbms/sql) backed applicatons, in the end a lot of the business world runs on spreadsheets... Not only that, but excel, and I'm assuming plenty of others have integration points for pulling data from other resources... Spreadsheet masters can do very impressive things with what appears to be a simple tool.
I've seen suppliers using google sheets for a list of tens of thousands of items. Also color coded and filterable and what not. It worked. I could access it programmatically, I had no complaints. (Especially with an experience of some of these suppliers having shitty hosts and shitty platforms and their massive XMLs taking forever to load.) Then again I'm sure I would speak differently if someone just decided to rename a column randomly :D
We have no idea if its a good solution or not. It depends upon, among other things: how long it takes to update it, the error rate, and how acceptable those errors are.
I think the correct answer would be to ask "why are they doing that and not using Google Sheets?".
There are a lot of good reasons for not using Google Sheets. Maybe the spreadsheet is using features that Google Sheet doesn't support, maybe one of the parties is in China, where Google services are blocked, maybe it is against company policy to use Google Docs, maybe they have limited connectivity.
It is good to acknowledge the obvious, off the shelf solutions, but if you are given a job, that's either because the customer did their homework and found out that no, it is indeed not appropriate, or, for some reason, they have money burning their pockets and they want a custom solution, just because. In both cases that's how you are getting paid. So, I don't consider "use Google Sheets, you idiot" to be an appropriate answer. Understand the customer specific needs, that's your job, even more so in the age of AI.
And maybe the interviewer will be honest and say "just assume you can't, this is just an exercise in software architecture".
> 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.
Last year my team had to remove all the phone numbers from 50,000 Amazon web page templates, since many of the numbers were no longer in service, and we also wanted to route all customer contacts through a single page.
Let's say you're on my team, and we have to identify the pages having probable U.S. phone numbers in them. To simplify the problem slightly, assume we have 50,000 HTML files in a Unix directory tree, under a directory called "/website". We have 2 days to get a list of file paths to the editorial staff. You need to give me a list of the .html files in this directory tree that appear to contain phone numbers in the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.
How would you solve this problem? Keep in mind our team is on a short (2-day) timeline.
In Yegge's case, he explicitly does NOT want a hand-written program, he wants the candidate to suggest a CLI tool, e.g.
These questions aren't good or bad unto themselves, but when the person asking is engaging in "Guess the answer I'm thinking of," don't beat yourself up if you guessed wrong. Your answer might be prized by someone else with an enormous amount of experience hiring engineers.
A former coworker was evaluating the cleanliness and structure of some non-free GeoIP data that took the form of several large CSV files. He was writing nested loops in Go that parsed the CSV and evaluated the predicates that interested him, and it was arduous and not going as quickly as he would like.
I told him to slurp it all into a sqlite database and to express his data integrity questions as SQL queries.
It was still a pain in the ass for him, but leveraging that tool made things go a lot better.
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.
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".
I attach a copy of the file and then provide a network location for where it is located. Makes it easy for people to just open up a simple copy to look at it and they know where to go to access the original.
I've stopped playing the game of 'guess what the right answer is'
I would have said the exact same thing and pushed the interview to consider 'why are we creating a tool when something off the shelf solves our business needs? What kind of runway and resources do I have to meet this goal? What is good enough for our problem here? Do we want to expand our scope to enable external data integration and downstream data consumption"
You will find better employment outside the circus, possibly even selling to the circus
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.
Is it? I have long thought that most things business people are using a spreadsheet for belongs someplace else. They are easy ways to run quick what-ifs or make lists, but generally the right answer is update the system so they don't need a spreadsheet. If the data is financials - why can't your accounting system give everyone the view they need from the shared system? Othertimes what they really need are a database to track this. But a spreadsheet is easy and so they ignore all the problems it creates because it needs a real engineer (and often more money than they can spend) to create the right solution.
> it needs a real engineer (and often more money than they can spend) to create the right solution.
Then it's the wrong solution. Period.
There are plenty of annoyances with spreadsheets, but part of what makes them so robust and powerful is that they don't take a ton of specialized knowledge, and they remain incredibly flexible.
An expensive, complicated, static, "right" solution for a small business is folly (honestly - this stays true up to medium/large business). It's a ton of time and energy focused on the absolute wrong thing. When a spreadsheet can reach the same result in a fraction of the time.
Especially given the result may not actually be that important, and they pivot to something else entirely in the very near future.
I've worked at several startups. I'd caution even software startups from assuming that custom solutions are the right approach. They usually aren't. They're a waste of time and effort that ends up saddling you with a brittle, expensive solution designed to solve problems from last year.
You are missing something: how much is spent because the spreadsheet isn't the right solution - nobody measures this (or even knows how). How much are you risking because spreadsheets are not robust - when will a mistake catch up, and what will be the cost? There is a reason accountants use double entry bookkeeping, and spreadsheets don't have that.
Nobody has the money to spend doing things right unless they have been burned. That doesn't mean the money shouldn't be spent first.
Spreadsheets are powerful I will grant. However they are not robust. A robust system works very different and includes features (like tests) that your spreadsheet doesn't have (I don't if it could have them, but it is safe to guess they don't)
I didn't quite mean it that way. My question is basically asking "Does this hammer know that not every problem is a nail". To give a specific answer to your question, my accounting system is excel, and "everyone" is me. There are definitely plenty of places where a database makes sense. But it's also important for database engineers to understand where databases don't make sense. It's kind of like that old problem we had where people would keep on saying "We can do X with blockchain" and the typical answer is "ok but that's worse".
There are plenty of reasons that a department within a company will prefer spreadsheets. Software is not the answer to everything and also this is the same problem you get when Microsoft introduces those pesky 'Power App' developers etc or previously the Sharepoint 'web parts' etc....essentially someone who kind of feels they are the 'owner' of some information then decides to formalise the process in their own little way.
Now you have a person wasting a bit of time making their little tool but you've also got people complaining that someone's now essentially taken control of it etc. At a former employer our procurement team used spreadsheets to track basically everything but importantly everything on our PCBs - every single component and their suppliers and prices etc (various factories around China usually). This would have been a horrible thing to try and formalise in a web app just because of how often they were all changing their own conventions etc (often suppliers changing what information they gave to them, too). It would have been a wild goose chase to formalise it and more than the trouble it would be worth.
I just wish that in those cases the interviewee gives feedback and allows you to rewrite instead of just failing you. I mean in practice nobody writes library functions themselves unless absolutely necessary, but I get that for some positions you have to demonstrate that you can write lower-level code if you have to.
I think that it was probably a poorly designed question, but surely you could throw the interviewer a bone by giving a custom answer after they reject the library.
I love how your answer was straight, to the point and leverages existing standards, then scrolled up to the question and had to go through someone else's thorough, multipage response. Full marks to both answers!
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.
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
Not an engineer but reminds me of a similar situation I've seen interviewing
Sometimes we'll ask market sizing questions. We will say it's a case question, it's to see their thought process, they're supposed to ask questions, state assumptions, etc.
Occasionally we'd get a candidate that just doesn't get it. They respond "oh I'd Google that". And I'll coach them back but they just can't get past that. It's about seeing how you approach problems when you can't just Google the answer, and we use general topics that are easily accessible to do so. But the downside is yes, you can google the answer.
I get that "communicate your thought process" or "play along with the exercise" gets offered as the fix here. But that framing bothers me too. Why should simplicity require more justification than complexity? Google Sheets is the design. The fact that it doesn't sound like engineering is the whole point.
I'm just not convinced the solution is learning to package simplicity in a more impressive wrapper.
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 really depends on how much time is spent filling out the spreadsheet.
If they are collectively spending 1hr/mo on the spreadsheet then it’s not worth an SWE’s time to optimize it. If they are spending 4hr/day on the spreadsheet then it’s a prime candidate for automation.
I feel like you could start waxing poetic about engineering value of meeting people where they are, not reinventing the wheel, etc.
Then after a brief discussion of that you could actually ask if the purpose of the question was for you to design a system to handle that situation and jump into the design.
The awkwardness after your answered was the interview telling you something important. A team that penalizes picking the right tool over an impressive one is a team where you'll spend years creating complexity nobody needs.
The lesson isn't "next time pretend Google Sheets doesn't exist." It's that you found out early what they actually reward.
The annoying thing about corporate hiring practices is – speaking from experience – some of us would have loved your answer. But then it goes to committee and someone's like, "this iOS engineer doesn't know any javascript, and I'm an expert in javascript, so I'm a 'no'."
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.
> 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.
> The point is to understand the candidate's thought processes
The problem is that this is a 2-way street. The candidate is forced to guess the interviewer's thought process, because otherwise they may be pitching over the interviewers head.
We have to spend a ton of time calibrating hiring loops for this, because otherwise you get staff level candidates being failed by mid-career interviewers who don't understand the full context of the question they are asking (and hence don't understand why a staff eng solves it differently than they would).
I think you could start saying that there are multiple options. The simpler is sharing the sheets in Google (or Microsoft) Sheets. After this, Then, I would have asked if there are any security and/or compliance issue to doing so to analyze other alternatives.
I would have said "Move them to Google Sheets, but I gather from the nature of the question this is about finding a solution to build from an engineering standpoint..." and then go into ideas for how to collect user research, and apply those findings to a new tool build.
Yours was a clever answer to a stupid question. Tech interviewers need to leave college behind and start treating candidates as professionals. Puzzles, white boarding and riddles are unique to software engineering roles, you would never see a lawyer, an accountant, a doctor, or engineers in other disciplines going through any of this nonsense. These methods are proven to be a poor predictor of job performance. In my last role as lead engineer we would chat with the candidate over lunch about random topics. We first wanted to see if they would fit our team. Then in the afternoon let them work in a little project that was actually part of active development. This way we discovered that most candidates who went through the screening process could actually be pretty good team members. Our issue was having to decide who to give the offer to, while other companies keep rejecting candidates over bubble sort. Our attrition was also pretty low. So it happens that software engineers will surprise you when you treat them as grown ass adults. Who would have guessed?
Honest question: did you really not read the room there?
I mean, if I were on the interviewer side, asking that question, and getting an initial answer "Well, to be honest I would tell them to use GSheets because given the current situation is the highest benefits/costs solution, but for the sake of a system design interview I would also think about designing a bespoke internal solution that would use blah blah blah". You would get a "strong hire" evaluation and you would still be able to turn down the offer if you wanted because that question might have been a red flag to you.
Run or email their seniors and ask them if they're hiring for higher-up positions.
But this is connected to another thread on HN about engineer/manager titles and how they basically have no value if you try to compare them between employers.
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.
I mean that's not really a good answer because you need to ask why they are sending a spreadsheet back and forth. Like yeah using a shared spreadsheet saves them having to email back and forth, but it doesn't help formalize the process, include validations, or make the data available to other systems. And maybe it would turn out that none of that is actually helpful in this case, but if you don't make an effort to ask and understand what's going on then you won't know if there's some bigger problem that needs addressing.
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.
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.
People on call will use AI as well. As long as the first AI left enough documentation and implemented traceability, the diagnosing AI should have an easier time proposing a fix. Ideally, AI would prepare the PR or rollback plan. In a utopia, AI would execute it and recover the system until a human wakes up.
Or at least there is something to chat with about the issue at 3am.
This. I've been a sysadmin for a quarter of a century and have professionally written next to no software. I've debugged every system I've had to support at some point though. It's a very different skill set.
True, but I think the implication (as I read it) is that AI may be providing more complex solutions than were needed for the problem and perhaps more complex than a human engineer would have provided.
it's MUCH worse now, not just because of the massive amount of code generated with zero supervision or very little supervision, but also because of the speed at which the systems grow in function
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, or you use money to buy a tool that solves that problem, well then it's still your job to solve that problem regardless of which tool you use.
But given how poorly bought software tends to fit the use case of the person it was bought for... eventually generate-something-custom will start making more and more sense.
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. Overall I think it'll be an improvement because there will be less distance (both in time and along the social graph) between the software's user its creator--them being most of the time the same person.
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"
It reminds me a lot of people who take Code Complete too seriously. "Common sense" is not an objective or universal statement unfortunately - plus, speaking for myself, what I consider "common sense" can change on the daily, which is why I can't be trusted adding features to my own codebase long term <_<.
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.
Awesome! However, the corporate is excited with using AI, making the coder the one who's at risk at getting fired for writing the exact same lousy (for the sake of the argument) code.
Or worse: for not relying as much as possible to the AI who apparently can write just as bad code but faster!
A subtle detail: you speak of coders, not software engineers. A SWE's value is not his code churning speed.
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.
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"
This seems like a perfect use case for a local model. But I've found in practice that the system requirements for agents are much higher than for models that can handle simple refactoring tasks. Once tool use context is factored in, there is very little room for models that perform decently.
Whatever agent I tried would include thousands of tokens in tool-use instruction. That would use up most available context unless running very low-spec models. I've concluded it's best to use the big 3 for most tasks and qwen on runpod for more private data.
I think this is at the moment the practical limitation to using AI for everything (and what the coding agents themselves also optimize for to some degree, or it's the slider they can play with for price vs quality, the "thinking" models being the exact same, but just burning more tokens).
Am waiting for the next Mac Studio to come out to experiment with the "AI for everything" approach. Most likely, the open source distilled models will lower quality. So, another "price vs quality" tradeoff. Still, will be fun to code like I'm at a foundation lab.
This is something I keep thinking while coding with AI, and same with introducing library dependencies for the simplest problems. It’s not whether how quickly I can get there but more about how can I keep it simple to maintain not only for myself but for the next AI agent.
Biggest problem is that next person is me 6 months later :) but even when it’s not a next person problem how much of the design I can just keep in my mind at a given time, ironically AI has the exact same problem aka context window
There's also the operational cost of running whatever is churned out. I wouldn't exactly blame that on AIs, but a large contingency of developers optimize for popular tech-stacks and not ease of operations. I don't think that will change just because they start using AI. In my experience the AI won't tell you that you're massively overbuilding something or that if we did this in C and used Postgresql we'd be able to run this on an old Pentium III with 4GB of RAM. If you want Kubernetes and ElasticSearch, you'll get exactly that.
AI generators only generate that if you tell them to though - as a developer (especially senior) it's your job to know what you want and tell the AI coding tools that.
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.
There's different kinds of abstraction. There's abstraction like Jackson Pollock and there's abstraction like what Dijkstra as suggesting: elegance. Which personally made the article a very weird read to me
tbh codebases like that predate AI code generators. I had one job where my predecessor was not a very good developer by modern standards, but he was productive... a dangerous combination.
I also kind of respect it, it bothers me endlessly when everything isn't perfect and this guy just threw caution to the wind. Jokes on me as I'm working for him now. But it's not like anything that predates AI, I couldn't write this type of slop if I tried lol. Zero formatting, linting, or anything. Just straight goulash.
I feel like the article is conflating simplicity with minimalism. Just doing the minimum of whats asked isn’t in itself enough to differentiate great vs ok.
Simplicity is worth recognizing only when the person started with a complex problem and ended up with a relatively simpler solution.
For a straightforward ask you will have people who will just build a hut and another will build a campus, who is right really depends on many factors and time.
Ironically, this article is "over simplifying" the problem.
In the FAANGs I've worked at, engineers who come from scrappy companies and implement hacks (Like the example of emailing spreadsheets around) undermine the business and will cost the productivity of thousands of people.
However, at the startups I've worked at, the folks from big companies that try to implement a super complex thing (e.g. exotic databases, overly ambitious infrastructure) The results are equally catastrophic for a company attempting to bootstrap when the complexity is so far removed from their core business.
What makes an experienced engineer is recognizing both states, understanding what works where and making the right trade-offs, usually from experience you can't fake your way through. I've seen a lot of projects that took 10-20 engineers 18 months to so we could sell something that landed a $100M contract with a customer. You see that enough times and you won't bias as hard against complexity. But of course it's situation dependent, like anything.
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 confess I assumed that the spirit of that award was more in "using what you have" than it was in making a simpler solution? They definitely over indexed on how clever the door desks were, though.
It is funny how much people assume quality from appearances, though. Same for costs.
One of my the papers I share around a lot is "Nobody ever gets credit for fixing problems that never happened (2002)"[1]. I like it because it's not purely about software so the examples resonate better with some exec level people in other teams I work with.
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.
Measure no, but only engineers care about that (and I'm not even saying that they're right, engineers care a whole lot too much about hard data). You can show alternative solutions, estimate, make assumptions, even make up numbers and boom, you have "data" to show you improved things. You don't even have to lie: you can be very open that these are assumptions and made-up numbers, that it's just a story, what's important is that people come out with confidence that thanks to you, things are better by a bit/a lot/enormously.
You can. GitHub is about to hit zero nines of uptime[0].
But feedback like that is far too late to be useful.
Maybe (principal or senior) engineers should be the ones to judge, and be trusted by management that their foresight is worth pushing the deadline?
You can't. You can hypothesize about the counterfactual in which you shipped a "steaming pile of complexity," but you definitionally cannot measure something that does not exist.
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've found simplicity rarely earns promotions because it's invisible on a P&L and executives respond to hard numbers. In one role I converted a refactor into a business case with a 12-month cost model, instrumented KPIs in Prometheus and Grafana, and ran a canary that cut MTTR by 60% and reduced on-call pages by two-thirds. Companies reward new features over quiet reliability, so slow feature velocity for a quarter while you amortize the simplification. If you want the promotion, make a one-page spreadsheet tying the change to SLO improvements, on-call hours saved, and dollar savings, then own the instrumentation so the numbers are undeniable.
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"...
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.
Thanks for the sane take. This article is engagement-porn for every engineer who ever looked at a system they didn't understand and declared they could do it much simpler. It's not because people love to promote complexity-makers, soothing as that thought might be.
> "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.
As a manager, I preferred engineers that delivered simpler code, but I also ran a team of experienced, high-functioning coders. I suspect teams with many less-experienced people get The Parable of The Toaster[0].
I'd add one point to this, as someone who voraciously fights against complexity at every turn, more and more as I get older. I've experienced times where leadership/management will assume that you're fighting against the complex solution simply because you don't grasp or understand it. It's irritating at best.
The longest lived projects and solutions I've worked on have always been the simplest, easiest to replace solutions. Often derived from simple tests scenarios or solutions that just work and get shifted over without much re-work.
What's somewhat funny, with this is that AI code assistants have actually helped a lot with continuing this approach for me... I can create a stand alone solution to work on a library or component, work through the problems, then copy the component/library into the actual work project it was for. I'm in a really locked down internalized environment, so using AI for component dev is on my own hardware... but the resulting work is a piece that can be brought in as-is. No exposure of internal data/resources.
I don't think I'll have a level of trust to "one-shot" or vibe code solutions from AI, but leveraging the ability to spin up a project as a sample to test a component/library is pretty great to say the least.
To add to this, sometimes leadership will assume (or even imply) that there's some laziness involved in not wanting to jump immediately on-board with the complex proposal.
I often end up saying, "I can build this, and I will build this if product insists on it, but first let me suggest an alternative ordering of deliverables that starts with a simple implementation and moves towards this one." In almost every case, that simple implementation is still what's in production years later.
Lead time for "how long until we can start using it" is one that is hard for a lot of folks to really take into consideration. There are terms for this, "earned value" and such. I have rarely seen them used in such a way that the planning actually worked out, long term.
The example he gave where each dev gets a single feature done seems to skip over the opportunity that Dev A has - after she spends only "a couple days" on that feature to ship a simple solution, she now has the rest of that week to do another feature, and another... in fact, she could probably get 6 features done in the time that Mr. Complexity took to do his one feature (3 weeks in the straw-man example). Then the promo packet looks much better for Dev A - while it says "implemented feature X", it also says "implemented feature A, feature B, feature C...". Doesn't that seem more attractive?
Slightly related: I've noticed that there are lots of "ideas guys" (yes, guys) in our field who love to bloviate, and maybe even accomplish some stuff that looks really good. I have made a career out of just putting my head down and getting shit done. I may not have grand design ideas, and in fact have had to unlearn the "fact" that you need to come up with, and implement, Big Ideas. In my experience, people who "get shit done" may not get fancy awards, but their work is recognized and rewarded.
I think sometimes flip side is that the engineer looks like they just shipped a bunch of "small features" A, B, C... because the solutions were so simple
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?
AWS loop a long while back wanted me to design a playlist system so my dumbass brain snapped to m3u files or w/e people were using back then and designed a system to host/share playlist files. The teenager (ok probably in their 20s) interviewing me seemed more and more confused as we went on but he never tried to redirect me to what he really intended.
Most people forget that the early web was built in server closets on-site handling hundreds of requests per second. The business was sold hyperscalers because devs wanted more servers and were tired of arguing WHY they wanted more servers. Then they got sold on Highly Available services because every second you're down is a dollar, or more, lost. Nobody mentioned that the cost of building and maintaining it costs more than the money you'd lose except for the largest of organizations.
Don't even get me started on the resume-driven development that came along with it.
And maybe I'm completely wrong. This is a perspective of one.
Honestly I think that the real result of this is developers that don't really understand the underlying tooling and invent all sorts of bad architectures.
One common example I cite is at one job I owned Kafka and RabbitMQ clusters. Zero consideration was given to message size recommendations and we had incidents on the regular because some application was shoving multi-hundred megabyte messages into RMQ. They'd do other stupid shit like not ack their messages which would cause them to never be removed from local disk. This was a huge org, public company, hiring "only the best and brightest".
Management endlessly just threw more hardware at it rather than make the engineers fix their obviously bad architecture. What a headache. Some companies take the "prioritize engineer happiness" thing right off a cliff.
I 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.
I'm extremely cautious about complexity, yet have adopted a claude-based dev flow. It comes down to watching and guiding it, and not letting it run autonomously. At a certain point your codebase will tip over into the patterns you've defined and claude will recognize and follow them. Just treat Claude as a vim editor mode and you will see a big difference, and your relationship to the tool will change.
The only solution that I've found to work, somewhat, is to plan with it to design the APIs exactly how you want it, atleast the public facing ones. It still does all kinds of mess in the functions but those are easier to cleanup on the next iteration cycle. If you let it design everything, it'll definitely go overboard.
That's an interesting question ... how should a less experienced developer use AI productively, and learn while developing? Certainly using it as a magic genie and vibe coding something you are in no position to evaluate is not the way to go, nor is that a good way for anyone to use AI if you care about the quality or specifics of the end result!
There's always going to be some overlap, wanting to use a new skill/library in a production system, but maybe in general it's best to think of learning and writing/generating production code as two separate things. AI is great for learning and exploration, but you don't want to be submitting your experiments as PRs!
A good rule of thumb might be can you explain any AI-generated design and code as well as if you had written it yourself? If you don't fully understand it, then you are not in a good position to own it and take responsibility for it (bugs, performance, edge case behavior, ease of debugging, flexibility for future enhancement, etc).
I very much agree with that, I had the same thought a few days ago.
I feel/am way more productive using chatgpt codex and it especially helps me getting stuff done I didn't want to get started with before. But the amount of literal slop where people post about their new vim plugin that's entirely vibecoded without any in-depth thinking about the problem domain etc. is a horrible trend.
Simplicity is hard. Mark Twain's 'I would have written less had I had more time' at the end of a letter comes to mind.
Software dev's tendency to build castles is great for technical managers who want to own complex systems to gain organizational leverage. Worse is better in this context. Even when it makes people who understand cringe.
You would think that things not breaking should be career-positive for SysAdmins, SREs, and DevOps engineers in a way it cannot be for software devs. But even there simplicity is hard and not really rewarded.
Unix philosophy got this right 50 years ago — small tools, composability, do one thing well. Unix reimagined for AI is my attempt to change that.
Relatedly, I'm periodically thinking about the issue of people who prevent problems not being rewarded as much as those who become "heroes" for resolving avoidable situations
I guess it may be important to underscore the value that simplicity provides over needless complexity or to sell people on the value of problems prevented rather than preventable catastrophes that were dealt with
Maybe we could encourage a culture of patting people on the back for maintaining reliable "boring" systems
Some people also crave "drama" so there might be a way to frame "boring reliability" as some kind of "epic daily maintenance struggle that was successfully navigated"
You’re thinking along similar lines as I am. The article talks about “visibility” in the end. This might be a document that is written. Or it could be a demo thats shared. Or a simple shout out in slack.
As engineers, we tend to keep away from the limelight and quietly get shit done and be happy with it. But professional growth and recognition requires visibility somehow. We need to be creative on how to achieve that.
The difference between the fire fighter and the fire safety inspector. The former puts out fires and saves lives and is of course a hero. The latter complains about things that never happen, wastes everybody's time and money and is generally annoying.
It seems like the safety inspector might be closer to a SOX compliance auditor or something... in this metaphor, the engineer who doesn't build something that "catches fire" is just the one who uses sensible materials, includes smoke alarms in the design, and chooses to use passive insulation in the walls instead of electric space heaters on a high-pile rug.
In my engineering job of over 30 years, I've noticed that the heroes that get rewarded for fixing the problems are usually the same ones who created the problems in the first place.
I've only been a paid-on-call firefighter for 10 years, but I have yet to work with any who are also arsonists. ;)
The name of the game is framing. You don't talk about simplicity, because most people don't really understand what simplicity is. They falsely equate it to easy.
Instead you talk about how you complete all your tasks and have so much bandwidth remaining compared to all your peers, the beneficial results of simplicity. Being severely under used while demonstrating the ability to do 2x-10x more work than everybody else is what gets you promoted.
In this vein simplicity is like hard work. Nobody gives a shit about hard work either. Actually, if all you have to show is how hard you work you are a liability. Instead its all about how little you work provided and that you accomplish the same, or more, than everybody else.
Exactly, simplicity is a subjective term; some think of it as in Clean Code where codebases end up as oneliner functions or overly formal lasagna code with many clean-feeling layers, but they can't see the resulting complexity in the overarching architeture.
Except you spend extra time making your code simple, rather than slapping together something that requires extra maintenance from the eventual owners.
Ideally we need metrics saying, "my projects require 30% less support or 50% less brainpower than comparable projects". Things like "average cyclomatic complexity", etc.
Simplicity is like any form of automation in that there is always an expensive upfront cost. The automation pays for itself by reducing time per interval, so its only a matter of when break even occurs as derived by the savings per interval multiplied by intervals in a given frequency.
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 agree. I generally don't ask "Do we need to future proof this?", I rather ask: "Do we paint ourself into a corner?"
For example, if you implement a job framework of things calling a REST API to do stuff async, a sufficient first implementation is a simple monolith doing the stuff and some retries or periodic calls. Because, if it does not scale, we can start thinking about replacing that with something to put things into queues and scaling stuff-doers horizontally and such. But often enough, these simple things scale quite the distance.
On the other hand, if you start introducing in-memory caches into a singular instance to taper around database performance... that's a huge issue. That always leads to pain.
Additionally though, I"ve started to keep notes about people doing simple, efficient things without fanfare. This way, if my boss asks me what Bob did over the year, I can tell them that Bob made these problems disappear and how Bob is starting to handle this area of topics more and more. Suddenly Bob is growing responsible for this area, and if my boss asks Bob about these topics they did well in an annual review, Bob can shine. Hope they learn though.
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?"
Ah, but it's worse than this. The truly ambitious ladder climber creates not just unnecessarily complicated abstractions, but organizations. Processes for people to follow. Infrastructure for people to maintain. Committees to vet changes. Standing meetings.
I actually got a job for deleting code. I was fixing a problem on a contract and noticed that I could fix the problem by getting rid of the section that contained the problem. The functionality could be provided in a much simpler way. Later the company created a position and I was given first refusal before they interviewed anyone.
It was a 8 bit embedded application in something like 10k of code. When I left I generated a short and clear explanation of why what I had done was awesome in terms of their future business ... because that is what you have to do if you work contracts. Which is the real message of the article. You have to write things up.
In my team, I've been working to help everyone do a task that's necessary, but because it was too difficult, people bypassed it. Over time, I made it simpler, others are joining to make it even simpler, but in the process, I'm not doing as many "feature tasks" as I could. I joke that people are mad at me every day, but grateful every week and month.
I had to stop trying to prove myself to the company. I have already done that when y'all interviewed me. Now I do what's best for everyone, and I want the company to prove to me that it deserves people who do the right thing despite the processes not valuing it. If it does not, I have enough resources to spend some time on the projects I cared about most.
This mentality gave me peace of mind and helped many people in partner teams go faster and with higher quality.
Management still does not openly appreciate it, but it shows in how they interact with me. Like when you learn to talk to your parents as equals. It's unexpected for them, but they quickly embrace the new interaction and they love it much more than the one before.
> 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.
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".
Fair. I work on backend, and there we usually need db replication, sharding, event brokers, monitoring and alerting, autoscaling. I wish we wouldn’t need all of that, and could use a single server with sqlite… but that won’t cut it.
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.
>I think there’s something quietly screwing up a lot of engineering teams. In interviews, in promotion packets, in design reviews: the engineer who overbuilds gets a compelling narrative, but the one who ships the simplest thing that works gets… nothing.
I got emotional reading this. This is way too real.
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.
In full-time employment this is sad but true. There is a way out of this toxic loop however.
As a consultant/contractor I always evangelise simplification and modelling problems from first principles. I jump between companies every 6-12 months, cleaning up after years of complexity-driven development, or outright designing robust systems that anybody (not just the author) can maintain and extend.
This level of honesty helps you build a reputation. I am never short for work. I also bill more than I could ever as a full-time engineer based in Europe.
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.
At core, complexity is derived from discovery of demand within those pesky complex humans.
Simplicity is the mechanism of finding common pathways within the mess of complexity of a product.
the tragedy is that simplicity is very expensive and beyond most organizations ability to support (especially since it can slow down demand discovery), and this is one of the allures of big tech for me. I was greatly rewarded and promoted for achieving simplicity within infrastructure.
I'm currently building a full-blown OpenAPI toolchain at work, where the OpenAPI document itself is the AST. It contains passes for reference inlining, document merging, JSON Schema validation, C++ code generation and has further plans for data model bindings, HTML5 UI...
Why? Because I'm working on a new embedded system which has a data model so complex, it blew past 10k lines of OpenAPI specifications with no end in sight. I said "ain't no way we're implementing this by hand" and embarked on the mother of all yak shavings.
I want all of the boilerplate/glue code derived from a single source of truth: base C++ data classes, data model bindings, configuration management, change notifications, REST API, state replication for device twins and more. That way we can focus on the domain logic instead, which is already plenty complex on its own.
I'm not designing all of this to be simple to develop. I'm designing it so that it's simple for the developers. Even with the incomplete prototype I have currently, the team is already sold ("you mean I just write the REST API specification and it generates all of the C++ classes for me to inherit?"). The roadmap of features for that toolchain is defined, clear and purposeful: to delete mountains of menial, bug-prone source code before it is ever written by hand.
Sometimes, it takes complexity to deliver simplicity. The trick is to nail the abstractions in-between.
This is the norm at large tech companies and, IMO, a huge problem and major detriment to productivity within organizations as the cost of that added complexity is paid by everyone.
BUT, at least very occasionally I have seen people get promoted for simplicity, I've even successfully made the case myself. With a problem that was itself so complex that it was causing fires on a regular basis, and staff & principal engineers didn't want to touch it with a ten foot pole. When a senior eng spent a couple of weeks thinking about the problem and eventually figured out a way to reframe it and simplify the solution, melting away months of work, making the promo case was actually quite easy.
The problem is, the opportunities to burn down complexity like that don't present themselves nearly as often as the opportunities to overcomplicate a thing, which are pretty much unbounded.
There's a related dynamic that I don't see discussed enough: simplicity is also harder to defend in design reviews because it looks like you didn't consider the edge cases. When someone proposes a three-table schema, the immediate question is "but what about X?" and the simple answer — "we handle X when X actually happens" — sounds like hand-waving compared to someone showing an elaborate diagram that accounts for every hypothetical scenario.
The irony is that the elaborate design usually handles those hypotheticals incorrectly anyway, because you can't predict real requirements from imagination. The simple version gets modified when real feedback arrives, and the modifications are cheaper because there's less architecture to work around.
Quite the opposite -- you get promoted for complexity and inefficiency, and pretending like you are the only SME who can handle it, thus creating a dependency between you and your manager. A good technical manager can see this coming a mile away. Bad ones don't but it costs the company.
The sad thing is that it is common to get fired when you make things better bc then your work is perceived as "done" and your skills are no longer necessary. There are countless IT job stories where someone delivers a technical solution that saves a company a ton of money or generates revenue, then they get fired bc the solution has been delivered and an off shore team has been hired to maintain the work.
Big corps suck.
Edit -- reading some the responses here on this topic and they are...eye-opening and depressing.
> 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?
That is very true. For whatever reasons - the bigger the company, the more unjustified complexity it cripples itself with without being aware about it.
Also survivorship bias is a very real thing (problem prevented is ignored, while problem solved is appreciated regardless of who and why caused it).
We've had an interesting experience on the interviewing side of this. Asking a system design question and getting answers involving multiple layers of caching, pub/sub, event-driven whatever/etc.. when the real answer is to just use postgres. It handles the scale we're asking about. We know it, as that's what we use internally.
I've only worked at my startup so I can't comment on scale elsewhere, but if our simple architecture can handle 30k requests per second, I think it can handle most other companies scale too.
There are two ways of constructing software: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
That's cute, but pure fantasy, imo. There's no non-trivial code that's actually used and maintained that's going to be immune to obvious deficiencies that get overlooked. Look at this [0], for example. Simple as can be, obvious defect in a critical area, left out in open source for ages, a type of bug an LLM would be liable to generate in a heartbeat and a reviewer could easily miss. We are human after all. [1]
The example in the story seems, if I may, "too simple."
Rarely have I seen an actually straightforward, simple feature that can be done in a day used as the basis to spin up a 3-week mini-project with a complicated new architecure.
What happens is a complicated-sounding feature is requested, and some devs will just take it literally and implement it, maybe along with some amount of "future-proofing" that logically follows because the spec is poorly scoped.
Other devs will spend some time thinking about it, realize that there is a really a simple requirement at the core of the request, and it only sounds complex because it was vaguely specified (or maybe these days an LLM was used to write the spec, and its vomit was copy-pasted verbatim). They just implement the simple thing that is the actual need.
This is one place where the agile/scrum practice of planning poker can help. You get a few smart people in a room, and discuss the story and its requirements. Hopefully someone will throw out a low number of points and say "isn't this simply asking for..."
Over my career, most of the complicated code I have written is no longer running. What is still running after 10 years? Postgres (or more broadly, a relational database). Fad frameworks or architectures come and go pretty quickly, they don't end up working as advertised, and it's on to the next thing. I no longer want to spend time in this hamster wheel churning out complicated code that will only end up as next year's tech debt.
Extends to the extreme levels of SaaS-ification of fairly basic app functionality as well.
It's often simpler to build something you know than to integrate a 3rd party service, but it's highly frowned upon by a lot of devs and management.
Auth and analytics are things I'm thinking of - we have good tools to build these in-house. Also just running a database - never seen so many people afraid of installing postgres and a cronjob to back it up.
I have a story about this; People had an HSM (in USB key form) which needed to be shared. The question came to create some elaborate piece of software for lending to prevent people from accidentally leaving it in their pockets and accidentally going home with it (which had happened a couple of times).
Instead I went to the hardware store across the street and bought the biggest (and cheapest) screwdriver I could find and attached it with some cord to the HSM. They never lost it afterwards.
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.
The structural problem is that simplicity accrues value slowly and diffusely, while complexity delivers visible credit immediately to whoever built it. The person who adds the abstraction layer gets the PR merged and the ticket closed. The person who deletes it six months later gets... a smaller diff and a shrug.
I've noticed the incentive breaks down even further when you consider that simplicity often means saying no upfront, which requires correctly predicting future maintenance costs that nobody has experienced yet. Complexity requires no such foresight. You just build the thing someone asked for.
The orgs where I've seen this actually work had explicit "deleted lines" culture, where removing code was celebrated as loudly as shipping features. Not many places do that. Most treat a 2000-line deletion PR with the same energy as taking out the trash.
Simplicity can be a powerful defence against complexity. When there are many ways something can go wrong.
Rather than trying to anticipate all the different failure modes one tries at first just to handle fact of failure itself, assuming there's no remediation.
If there's a way to make sure the worst case isn't terrible in some simple way then you do that first - like making a backup file or tr4ying to keep APIs idempotent so you can recover from issues and so on.
> Picture two engineers on the same team. Engineer A gets assigned a feature. She looks at the problem, considers a few options, and picks the simplest. A straightforward implementation, maybe 50 lines of code. Easy to read, easy to test, easy for the next person to pick up. It works. She ships it in a couple of days and moves on.
> Engineer B gets a similar feature. He also looks at the problem, but he sees an opportunity to build something more “robust.” He introduces a new abstraction layer, creates a pub/sub system for communication between components, adds a configuration framework so the feature is “extensible” for future use cases. It takes three weeks. There are multiple PRs. Lots of excited emojis when he shares the document explaining all of this.
So in this scenario two solutions are produced: Fast to develop but probably brittle (it is not described as robust, but it is described as easy to change), slow to develop but not brittle (but perhaps too complex and likely hard to change).
Both fucked up. Engineer A stopped too soon, and Engineer B built too much up before any value was realized.
You want Engineer C: Makes the fast solution that gives you feedback (is the feature worth pushing further? do users want/need it?), and continues to produce a more robust solution that won't crap the bed.
Engineer A is a potential chaos agent, tossing out and abandoning work too soon. Engineer B is a bottleneck who will waste weeks or months producing invalid solutions.
In larger systems, what looks like “overengineering” can be deliberate risk management. In my experience, senior engineers do get promoted for simplicity but only when they can articulate the trade-offs and the future costs they are avoiding.
You need the tension between both, or else either approach at most levels of systems, whether its an app or a corporation, tends to lead to toxic failures modes.
It could be something overbuilt, large organization structures. Brittle solutions that are highly performant until they break. Or products/offerings that don't grow for similar reasons, simpler-is-better, don't compete with yourself. Or those that grow the wrong way-- too many, much to manage, frailty through complexity, sku confusion.
Alternatively, things that are allowed to grow with some leeway, some caution, and then pruned back.
There's failure modes in any of these but the one I see most often is overreaching concern for any single one.
Maybe I am naive but I still believe that simplicity leads to personal wins in the long run. Having simpler system designs lead to velocity and eventually you become known as the "team that can deliver".
The article's point is sound, but its missing a key component. People who build simpler systems are capable of getting more done - the build takes less, the maintenance takes less, etc. So when the engineer choosing simplicity is looking to get promoted they might have 3 or 4 bullet points to their name instead of 1.
Of course, over-simplification is the wrong decision some times, the same as abstraction and complexity is the wrong decision some times...
Your shortcut for promotion is generally building value for the company, but people need to remember that promotions support the business and they aren't free to the company.
Unfortunately, no, simpler systems often take longer to create. It's always easiest to just add some janky widget hanging off the side, than to rejigger the whole system to be simpler. It's like the Pascal quote: "I have made this longer than usual because I have not had time to make it shorter."
They take less to review and maintain etc, but the credit for those positives aren't assigned to the original engineer. Which is the point of the article.
This is playing out in real time with AI. Someone uses ChatGPT to compress weeks of work into hours, and the organizational response isn't "great, let's scale this" -- it's panic about what it means for headcount and hierarchy.
There's a short film making the rounds that captures this perfectly -- an employee uses AI to generate the quarterly results his whole department was working on, and instead of being promoted, he gets fired: https://youtu.be/O5FFkHUdKyE
The simplicity penalty is even worse when the simplification comes from AI. It's not just "you made us look bad" -- it's "you made our entire team look unnecessary."
What's going on here? There's a AI generated song in a youtube video, but it was posted yesterday and this bot is here today. Did someone have future sight of what today's HN post was going to be?
Sounds like an inverse Peter Principle... the people who are best at their jobs will stay in that job while people who care enough about promotions to sabotage their work will get promoted out of a position to do damage.
FAANGs are notorious for promoting complexity, and the results are there for all to see.
One thing engineers can do to fight this, and I think it's mentioned in the article, is to write extensive documentation. Bosses in these companies are too lazy to dig into solutions and figure out for themselves; so they resort to proxies like the number of lines of code, number of pages in the design doc, etc.
Unfortunately, some of us who aim for simplicity are also averse to writing long docs; but with the advent of LLMs, there is some relief in sight.
My career has suffered a lot in terms of promos, etc. because I hate complexity.
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?
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupéry.
It's hard to keep things simple. Management should be mindful of that and encourage engineers to follow YAGNI, to do refactorings that remove more code than they add, etc.
You can sell simple solutions as complex by focusing on what they solve. No one has to know your solution is simple unless they're looking under the hood.
And complexity doesn't always sell better. A lot of times it might look like the whole thing is messy, or too hard to maintain, tech burden nightmare. Things that are simple might look complex and vice versa too, I think anyone who had to implement requirements from people who don't understand the implementation complexities will know this very well.
The incentive misalignment gets worse when you factor in hiring pipelines. A team that keeps their stack simple has fewer "impressive" bullet points for resumes, which makes it harder to hire senior engineers who want to work with "interesting" technology. So there's pressure from both ends — management rewards complexity, and talent acquisition inadvertently selects for it. The orgs that consistently reward simplicity seem to be those where senior engineers have enough credibility to push back and say "we already solved this with three lines of SQL."
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.
Sad but true. I'm very strict with my developers and extremely cautious of introducing new "moving parts" to existing systems. I try to keep a single deployment-unit if possible. I like monoliths.
I just refactored a bunch of our microservices into a monolith. Fortunately the business justification was pretty straightforward because it was clear to all of us that the service architecture was weighing us down.
Since one of microservice's benefits is solving a coordination problem, now that teams are getting smaller due to AI, I wonder if we will see monoliths make a resurgence in some cases.
Haha. This title: Nobody Gets Promoted for Simplicity
This was the model at my last job. The "director" of software had strong opinions about the most random topics and talked about them like they would be revolutionary. His team was so far from the product teams they would just build random crap that was unhelpful but technically demo'ed well. Never put into practice. Promoted for 4 years, then fired.
Just about every project I've ever worked on eventually needed everything.
So the way we write software piecemeal today is fundamentally broken. Rather than starting with frameworks and adding individual packages, we should be starting with everything and let the compiler do tree shaking/dead code elimination.
Of course nobody does it that way, so we don't know what we're missing out on. But I can tell you that early in my programming journey, I started with stuff like HyperCard that gave you everything, and I was never more productive than that down the road. Also early C/C++ projects in the 80s and 90s often used a globals.h header that gave you everything so you rarely had to write glue code. Contrast that with today, where nearly everything is just glue code (a REST API is basically a collection of headers).
A good middle ground is to write all necessary scaffolding up front, waterfall style, which is just exactly what the article argues against doing. Because it's 10 times harder to add it to an existing codebase. And 100 times harder to add it once customers start asking for use cases that should have been found during discovery and planning. This is the 1-10-100 rule of the cost of bugs, applied to conceptual flaws in a program's design.
I do miss seeing articles with clarity like this on HN though, even if I slightly disagree with this one's conclusions after working in the field for quite some time.
This is so weird to read given the quote at the top. The kind of simplicity Dijkstra is talking about is a form of abstraction. He's talking about elegance. While the author is talking about a different type of abstraction, more like the image or a Jackson Pollock painting. Look at how Dijkstra talks here [0].
When a scientist says "simplicity" they mean "elegance". This is very different from "easy to understand". There's a reason that quote says simplicity is difficult to achieve. This doesn't seem in line with the author's examples. But it's easy to see what Dijkstra was talking about. Have you ever derived an equation in math or physics? You start one place, do a whole lot of work, and then you get out this "simple" thing. You could write pages of math to come up with an equation that uses only a few symbols. E=mc^2 is simple but getting there was very hard and took a lot of time, thinking, and abstraction.
The author conflates simplicity with speed, not with what the end result is and how well it solves the problem.
Why are CS people against abstraction? All we do is abstraction? We act like all abstraction is the same, and it's evil.
We have to be more nuanced. I could see the entire blog post written in the exact other way where engineer A gets promoted because they complete more tickets and engineer B doesn't because they take too long. But the reality is that from such a high level we can't determine which solution is right. Sometimes A's method is the best and sometimes B's is the best. But we don't know the impact. B's solution could create more problems, like the author suggests, but also it could solve many problems that don't end up appearing. Same for A's solution!
I don't like this over simplification and the author's conclusion is naïve. If we make everything understandable to everybody then it's a race to the bottom Who does it need to be understandable to? The senior? An experienced developer? A junior? A manager?
Don't get me wrong, there's tons of unnecessary complexity out there and that's bad too. But for that I'll reference Knuth's famous and misunderstood quote where he says "get a fucking profiler before optimizing things". He too is talking about elegance, but a balance of how we should prioritize things.
This resonates so hard with me. I was self-employed for over eight years, since I was the one who had to deal with all messes I always made sure that things were as simple as sensible (but not simpler). I made a good career out of it. Then I went back to being employed by a company, and I was completely befuddled but the over-complication of designs. Engineers aren't trying to help the business or solve a problem, they're trying to prove how good they are. It's just the completely wrong set of incentives. If you only get promoted by solving complex cases and there are no complex cases to solve, then you'll make them up.
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.
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.
I think it's simpler than that, you get noticed and then maybe promoted based on what you deliver. The ability of delivering what you were asked to, on time, or even before that.
Adding extra things can always help, specially like in the UI side of things, since higher ups will probably just notice that part.
I just dont agree with this and it hasnt been my experience.
Your job is to deliver value. If you can get stuff done quicker and without it breaking, you did great. Some one who spent more time doing the same thing except took longer and has a more brittle solution they have to keep going back and fixing doesn't look good.
And simple solutions are easier to explain and convince people.
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.
By chance, recently in an architecture discussion document I added that one of aspects to consider is how easy is to remove (the whole thing) if it's not wanted anymore.
It was an obvious case because it was an AI capability, which can be become deprecated/useless/too-risky very fast.
Adjacent to it are PR reviews. Suggesting simpler approach in PR almost always causes friction: work is done and tested, why redo? It also doesn't make a good promotion material: keeping landscape clear of overengineered solutions is not something management recognises as a positive contribution.
Depends on the management and whether they're involved in coding. Any engineering manager, architect, senior / lead developer etc should appreciate lower complexity.
Of course, if it's the person in charge introducing said overengineering there is a problem.
they can recognise on the informal level, but you can't put it into end of the year review document. What it will be? "Kept N PRs from introducing cruft into our systems?". Fixing or building things is much more visible, than just maintaining high standards.
Worse, to suggest a simpler approach checking existing products/APIs or even preparing toy prototype is required to be confident in own advice. This hidden work is left entirely unnoticed even by well meaning managers/engineers: they simply don't know if you knew or had to discover simpler solution.
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).
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?
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.
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?
It's the definition of simple that's the problem. For any definition of simplicity you might have, someone has an equal and opposite definition.
Take these two alternatives:
class UserService {
PostgresDatabase db;
}
class UserService {
IDatabase db;
}
There are some coworkers who will veto the first example for being too complex, because it brings Postgres (and its state and connections and exceptions and mappings) into the scope of what otherwise could have been a service concerning Users.
There are some coworkers who will veto the second example for being too complex, because Postgres is all you use for now, and if you really need to use a second database, you can change the code then (YAGNI). Also the Interface gives you a pointless indirection that breaks IntelliSense so you can't just 'click-through' to follow the code flow.
I agree with your comment, but I disagree a both the example opinions... complex is the discussion :D
I heard something that helps better framing those discussions, use "familiar" instead of "simple".
An highly abstract way to access a database table, with ORM for example, can be simple because everyone is expecting it and knows how to do all tasks (changing schema, troubleshooting, managing transactions, etc.).
Doing userService.pgSql("select ....") in the same way can be simple.
I recently had a performance review at a FAANG. One engineer on my team has spent the past 3 years working on a complex infrastructure migration which involved about 20 engineers. The migration was completed last year and saved the company some opex costs.
I on the other hand spent 3 weeks optimizing our core service and reduced 2x the opex costs of the large complex 3 year migration.
In my yearly review my manager acknowledged my impact, but said I need to solve more complex problems to get to Staff Engineer. I protested saying that my 3 weeks of work had a larger impact than 20 engineers over 3 years, but he told me that is just how it works.
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.
Your plumber is probably making a good choice. Valves that don’t get exercised regularly can be all but guaranteed to be a pain in the ass when you need them to work.
We have a calendar reminder to exercise the valves in our house yearly, and the fact that they’re easy to get at helps make sure it’s a quick job, not a tedious one.
Not a plumber, but have lived in enough old houses with iffy valves to have been bitten a few times.
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.
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.
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.
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.
> 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.
I interviewed at a company that used a simple project to screen candidates. It was implementing a cash register checkout system. The task was soo simple that I couldn't figure out what they were looking for. So I implemented the simplest thing possible. I got the job partially because they were impressed by my utterly simple solution. I helped evaluate other candidates given the exact same problem and it's amazing how some people dialed up the complexity to 11. None of them passed the screening.
Promotion Driven Development at its finest. There's no good way to fix this without better teams and less Lord of the Flies style management. Servant leadership helps here, but if your team is adversarial in nature there is no escape. A manager that needs an exciting story to get a feather in their hat will take the story every time over "+20 -8000" commit style developers. Your product will suffer accordingly.
A lot of this boils down to promo system being so systematized. I've never heard of people in any other field min/max their promotions as hard along with all of the expert jargon in any other field I've worked in. Packets, peers, comp, other co comps, what your boss thinks of you, what your boss thinks of your peers (nee: competitors), and the inevitable crash out when they don't get the promotion. All part of the bigco experience! I feel like when we systematized comp into ranks Lx, Ly we gave up our leverage a little bit.
One more opinion piece uselessly recommending "simplicity" with no code samples or concrete takeaways.
> It also shows up in design reviews. An engineer proposes a clean, simple approach and gets hit with “shouldn’t we future-proof this?” So they go back and add layers they don’t need yet, abstractions for problems that might never materialize, flexibility for requirements nobody has asked for. Not because the problem demanded it, but because the room expected it.
$100 says the "clean, simple" approach is the one which directly couples the frontend to the backend to the database. Dependencies follow the control flow exactly, so that if you want to test the frontend, you must have the backend running. If you want to test the backend, you must have the database running.
The "abstractions for problems that might never materialize" are your harnesses for running real business logic under unit-test conditions, that is, instantly and deterministically.
If you do the "simple" thing now, and push away pesky "future-proofing" like architecting for testing, then "I will test this" becomes "I will test this later" becomes "You can't test this" becomes "You shouldn't test this."
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
The problem simplicity is facing is mentioned in TFA with the keyword "future-proof", which is the typical instance of FUD in software. It is extremely difficult to fight against it, as, just like fake news, it would take 10 times more effort to debunk it than to make it. Yes, you spell out the cost of the additional layer, but it is invariably answered with "that's not so expensive", and risk aversion does the rest.
Article seems to suggest that simplicity vs complexity is a sort of a binary, or at least a spectrum. In fact, it's very often the case that:
* You can have a bunch of simple code for a latent or implicit concept that is complex; and that making the code more complex might make the reflect principle simpler.
* You have trade-offs: If one aspect is simple, other aspects must become more complex to accommodate.
* There is no consensus over what constitutes complex vs simple code.
Well you do get promoted for simplicity if you outperform others, who do things too complicated.
For example, person A implements the simple solution, gets the project done faster while person B over engineers, has seemingly impressive stuff to talk about but at the end of the day doesn't ship.
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.
This is definitely a "known problem". At my company we call it "promotion-driven development". The promotion guidelines call out that knowing when _not_ to build something is important, but how do you put that in a body of work? "Decided not to build A". Nobody cares.
I feel this. I once worked for this manager, and whenever we finished a sprint, the first question he ALWAYS asked was "What tool(s) did you use/implement?" Many times, the answer was "No tools, I just banged out a bit of code to do the job.", only to get looked at for several seconds before he looked disappointed, and moved on. It was infuriating!
What in case engineer picks a simple solution that is hard to understand, cant be tested and next person that comes looks at it and says “wth is that?”
In case you ask “how can simple solutions be hard to understand and test?”
Lets just say you use single line bash scripts with multiple pipes, loops and very niche cmds.
It will work, it will look like nightmare, it will be simple -> one line.
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.
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.
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).
It's great to choose simple solutions to avoid over-engineering, but at the same time you need to be able to talk about them in a way that proves making that choice was much more complex than picking the complex path directly. Listing both the complex solution and the simple one shows others that you reasoned about both and deliberately chose simplicity. It's all about framing the story behind the decision.
When I'm on a team and there are multiple engineers and data scientists, many of them come from Big Tech: Google, Microsoft, Apple, etc. I don't get any points with them for implementing a one-liner that does whatever Google implemented but they get very excited if I did. I get a "Oh wow, I know someone who worked on that at Google, I am really glad it's useful!"
This extends to suggesting huge licenses like from Salesforce. The Marketing and HR teams are ecstatic that they can purchase another license of their favorite software, they can go shopping! If I had implemented a free and more efficient CRM, there would be no networking effect.
This all builds systems that are vastly more expensive (to the tune of hundreds of thousands of dollars), slower, and much harder to fix. YCombinator financially benefits from this and it's all very corrupt. Most of the time, I have to really gain the "soft skills" to activate the networking (nepotism) effects.
It's not about what you know, it's about who you know.
Yep people get promoted for bullshit throwaway projects that are built in the fastest & dirtiest way possible so that management can dance & clap about how brilliant everyone is about every 2-4 weeks.
All this is game theory top to bottom. The only way to really quantify productivity is to look at "how much" of a thing has been created. In this case, lines of code, features, files, etc... So of course people who want to maximize their own income through promotions will also be incentivized to maximize the only quantifiable thing that they're judged on.
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.
Having been both the interviewer and the candidate in this kind of situation, this is really a big interviewer training failure.
The general way to handle this as an interviewer is really simple: acknowledge that the interviewee gave a good answer, but ask that for the purposes of evaluating their technical design skills that you'd like for them to design a new system/code a new implementation to solve this problem.
If the candidate isn't willing to suspend disbelief for the exercise, then you can consider that alongside all of the other signals your interviewer team gets about the candidate. I generally take it as a negative signal, not because I need conformance, but because I need someone who can work through honest technical disagreements.
As a candidate, what's worked for me before was to ask the interviewer if they'd prefer that I pretend ____ doesn't exist and come up with a new design, but it makes me question whether I want to join that team. IMO it's the systems design equivalent of the interviewer arguing with you about your valid algorithm because it's not the one the interviewer expects.
A good interviewer won’t be looking for a single solution to the problem. I’d expect them to entertain the Google Sheets answer - it’s good signal that the candidate will consider what already exists in the world. I’d rather extend the problem: the team is spending considerable time iterating with manual entry, what would you do?
Complete agreement. "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?"
"That does sound like something nice to have. However, recreating Google Sheets is a substantial undertaking. First, we need to evaluate the business case for duplicating something that already exists to ensure that there is a net benefit in doing so. Second, we need to determine if the business has sufficient capital to see the project through."
There is a difference between being smart and acting smart.
That's a good real world answer, but a terrible SWE interview answer.
I suspect a lot of businesses are going to make this mistake in the "SaaS is dead" era as companies try to eliminate $50k/mo subscriptions for boring business software, and they figure it's easier to burn AI tokens creating an internal solution they didn't plan on maintaining in the far future.
Funny times we're in right now.
> "now what if we wanted to build it in-house?"
"Well I would probably go home and work on my resume because that's a fool's errand."
I hate going to work and reinventing wheels all day because the company I work for thinks it's so special that every business function needs a 100% tailored solution to solved problems. I much prefer working somewhere that's able to tailor business processes to conform to existing standards.
But maybe that's just me.
I’ve interviewed a few hundred people. Probably approaching a thousand, if not already. An interview is a scenario, and if you aren’t willing to engage in the scenario that we all agreed to partake in, that’s a huge warning sign that you’re going to be difficult later down the line. The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I'd call it an interviewer failure, not an interviewee failure.
I absolutely want people I hire to be "difficult" when the moment calls for it. If the scenario is one where the right business/user choice is "let them keep using Google Sheets", then the answer I want is "Google Sheets seems fine to me", no matter what people with more power start out wanting. Too many developers have been encouraged to be minions, not professionals.
Ditto for ones who act like everything is a nail for their coding hammer. A developer who can save a company a couple hundred thousand dollars by not turning something simple into a big coding project is a rare and precious commodity. Or should be, at least.
The thing to do isn't to give demerits for "being difficult". The thing to do is to then add something to the scenario where they get into the thing you want them to get to. "For this, we need better access control than Google Sheets allows us." Or, "We need this to be more closely integrated with our accounting system."
Unless, of course, what you're hiring for is the willingness to roll over for unreasonable requests from people with more power. Which, honestly, a lot of places are.
but also maybe its a green flag in that this employee might see the wood for the trees and save the company a lot of money later down the line. In my experience, a lot of engineers can waste a lot of time dicking around re-inventing wheels and whatnot.
While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate [0].
For reference, I think both answers are fine and both perspectives (its a positive or a negative) are equally valid. Its just that I don't think we can confidently state either way.
[0] https://www.youtube.com/watch?v=rZ3ETK7-ZM8
> While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate
Yes, I did. More than once. I always regretted it. Sure it could be a cognitive bias, but the entire interview process is essentially trying to figure out “can I work with this person”.
> I think both answers are fine and both perspectives are equally valid
I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
if you answer ""Well I would probably go home and work on my resume because that's a fool's errand." You probably are missing the wood and the trees.
and if you hire only based on solely on employee compliance then you are also probably missing the wood for the trees. I've worked in such orgs and they're extremely vulnerable to cargo culting.
I’m not hiring on compliance. I’ve accepted that his answer is correct but asked for the purposes of the exercise if he can put that to a side so we can talk about it. I’ve worked with and hired people like this and they tend to turn every molehill into a mountain, which is just killer on a small team.
I think you missed the point in GP's post. Not all organizations optimize for problem solving. Some organizations prefer subordinates who follow orders (or better, is able to read the mind of the boss to decipher what order he is actually making) than those who breaks out of the box and says ”just use gsuite, boss."
sure but if its not a privately held business then using gsuite is better for the shareholders. Ultimately its the bosses choice, but for the board to fire them its worth knowing they were aware of being able to use gsuite instead of pissing away resource on a needless project.
The question isn’t should we use gsuite, it’s can we talk about a tech problem. If you don’t understand that you’ve failed the interview.
Most real-world scenarios aren't so arbitrary, and hardly any have a "right answer". If I had a candidate that broke out of the box of our interview to give a good answer, and that's not the answer I "want", I'd be more likely to believe the interview question is the problem, not the candidate.
remember that we already did the "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?" part.
the "good answer" was already acknowledged, the "real-world scenario" answer was accepted.
the second part ("what if we wanted to build it in-house") is purely hypothetical to gauge how the interviewee would approach the specific technical challenge. if they again say "well that is dumb i would just use sheets", that is absolutely an interviewee problem.
> The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I think a lot of people miss this point.
Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.
Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.
In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).
I think the contrived scenarios you come up with need to not have a trivial solution. Everything about my brain is optimized for KISS, it breaks everything to turn down simple solutions to reach for something more complex.
Think of it this way: they're paying you lots of money to build something boring that has a lot of prior art/research available to you for free. This could be the easiest money maker in your life.
It's not your problem they're hellbent on building a new wheel. They're willing to pay you!
Chances are, you've thought of your own pain points in whatever they've asked you to build and you've now got an opportunity to shine by solving them and demonstrate your expertise.
There is a tool invented lately, that's very good for solving problems, that are well-researched and had been solved multiple times already. This tool is actually why there is a RAM shortage in the world right now.
Some even say, this tool will replace a lot of workers soon(sic!).
Setup Etherpad
The obvious way is to put the spreadsheet file on some shared network location.
You still need some "locking" mechanism so two people don't try editing at the same time.
Which again probably means Google Sheets is the best answer!
While I agree, how much training does anyone get as an interviewer? I spent 10+ years doing interviews at all sorts of orgs (including Fortune 500s, government, etc.) without a single hour of interviewer training.
Now that I think about it, none of those organizations ever trained me at anything at all. Huh.
> none of those organizations ever trained me at anything at all
They trained us repeatedly not to bribe foreign government officials, even though I had zero access to anybody like that. There was also some mandatory training against harassing coworkers. I.e. "protect the company from lawsuits" training, not "here are some ideas for how to do your job more effectively" training. They were megacorps, too.
> "protect the company from lawsuits
Yeah that's proven by the fact they get degree educated level engineers and force feed them videos designed for people working entry level positions. Its a crying shame because there's actually a lot of interesting discussions around nuance that are just sidelined by these videos creating basic bitch absurdities:
> During the lunch break, Jim has dipped his penis into Samantha's yoghurt
> is this:
> a) entirely acceptable, its just his culture
> b) a borderline issue
> c) something that someone should report to HR
Instead of:
Jane is developing feelings for someone that reports to her, they meet up outside of work and have a one-night stand. What should Jane do next?
> It's just his culture.
Wrong. Her yogurt, her culture.
That's unusual. Maybe that's a US thing? In Europe anywhere I've had to interview people I've received at least a couple of hours of training and then usually sat in as the shadow on at least one interview.
Quality varies, but I think it's only the super small outfits where I've been expected to just wing it.
> While I agree, how much training does anyone get as an interviewer?
TL;DR: not enough training.
As a hiring manager, whenever we start a hiring period I have a conversation with my interviewer team about what qualities we're looking for and review the questions they plan to ask in order to normalize the process. Stuff like "what does a good answer look like, and why? what does a bad answer look like? is this something easy for a candidate to engage with or will you spend half the interview just explaining the background? is this coding question unreasonably hard?" and so on.
I also look at the evaluations that interviewers give relative to other interviewers. Almost every hiring cycle I've done I've had to deal with some interviewer (all over the seniority spectrum) asking unreasonably hard questions.
Yeah, I had no training on being an interviewer before I started doing interviews. My manager gave me some tips, and I came up with two security bug-hunt exercises (was hiring AppSec engineers), but that was it.
Now, I wonder if I had rejected earlier candidates that I would have passed if I was a better interviewer.
The best advice I've had on interviewing is: Find an actual problem that your team is actually working through and ask the candidate how they would approach it.
Then to jazz it up: simplify the proble. To get to the root stuff that needs to be covered (e.g. ignore creating Jira tickets and focus on connecting to a database with cross-refion replication). You also want it to be simple enough that it can be solved in <30 minutes
Quite a bit based on the number of interviews performed at software companies. Being on either side of the fence gives you experience.
Same here. I receive a training budget at some places but it goes unspent. Everything is self directed learning in my own time.
Seriously? I worked at startups and research institutions. We trained people on interviews. I know Google used to invest quite a bit on interview training.
Sounds common to have training in big tech but I never received any training either. Sometimes we’d discuss changes we wanted to make to the interview process, which suppose could be considered adjacent to training.
I prefer pushing the constraints to motivate a different solution instead of asking them to do an unmotivated exercise.
“Google Sheets is a great solution for two people, but let’s say the department expands and now it’s ten people. How does this change your answer?”
It’s easy to break Google Sheets as a workflow by increasing the number of users, adding complex business logic, etc.
It’s interesting to see what candidates come up with and how they think. Sometimes the solutions are genuinely interesting. Mostly they’re not, which is okay. If you don’t give yourself the opportunity to learn as an interviewer, you’re missing out.
> this is really a big interviewer training failure.
Vast majority of interviews are pretty bad. I can only remember one or two interviews that did not colossally suck in some way.
It takes a lot of practice to become good interviewer and majority of ICs especially at small shops never get the required mileage. I don't think i really knew what i was doing until like 100 sessions in...
Thats fair, it definitely sucks for those seeking employment to have a really awful interview. How do you turn it around without looking like an a-hole…
At google where i started interviewing it worked pretty well at least initially when recruiters assembled panels such that you only get 1-2 inexperienced interviewers out of 6. They also didn’t let you do screens as fresh interviewer where it’s much harder to get signal. Every other place i worked it was basically a crapshoot
If I would be the interviewer in this kind of situation, I would just follow up with something like this: "that might be a good option, but let's assume you need to build a tool to replace those excel sheets, ..."
Surprisingly often you do get an interviewee who just won't accept the premise of the hypothetical. I've had people get hung up on the equivalent of 'but I'd just use excel' even with prompting/nudging/explanation that this is an exercise.
“Yeah okay forget sense, show me how good you are at budget protecting overdesign”
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
Maybe 10 years ago I interviewed both for Netflix and Facebook.
At Netflix, I used a state machine library to handle the project they gave me. Got rejected because I didn't show I knew raw JavaScript enough.
At Facebook, I wrote a calendar dropdown from scratch. Got rejected because I should have used a library.
Interviews sometimes is just a lottery...
Yes I know both companies should have set the expectation, but you can set the expectation for EVERYTHING, otherwise you give candidates all the answers you're expecting. There's always going to be some chaos due to the huge number of variables.
It's both.
As a hiring manager I've had situations like this arise because there was a gap in my plan and I didn't realize it. When those come up, we thank them for their cleverness, apologize to the candidate, reframe the situation, and give them another shot.
But also sometimes I leave intentional ambiguity in the plan. Part of the goal is to see if they have a degree of common sense commensurate to their level. If they're interviewing for a high level position, I'd expect them to be able to spot silly flaws and push back that perhaps the whole problem needs rethinking. And of course, I also expect them to know the brute force solution as well. Do they only know one? Both? Let's fine out.
> and give them another shot
Isn't this rather giving yourself another shot.
Of course, but the point is you don't fail a candidate for this. Some people do, including some of the examples to which I was replying
Postgres might have been a perfect answer, but the candidate needs to explain why and how.
The purpose of the interview is for the candidate to demonstrate their thought process and ability to communicate it. “Just use Postgres” doesn’t do that.
This would be more obvious if it was a LeetCode problem and the candidate just regurgitated an algorithm from memory without explaining anything about it. Yeah it’s technically the right answer but the interviewer can’t tell if you actually understand what you’re talking about or if you just happened to memorize and answer that works.
Interviews are about communication and demonstrating thought process.
100% interviews are about communication and demonstrating thought process; after going through some rounds of interviewing candidates myself, any candidate who can adequately explain what they're thinking and how they arrive at their conclusions will be able to demonstrate their skills much more thoroughly than 'just use Postgres'.
That being said, it's also on the ones giving the interviews to push the candidates and ensure that they really are receiving the applicants best. The interviewers don't want to miss potentially great candidates (interviews are hard and nerve-wracking, and engineers aren't known for their social performance), and thus sometimes need to help nudge the candidates in the right direction.
Fully agreed on the point that interviewers should prompt and push candidates in the right direction.
The best thing someone can do to learn how to perform well in interviews is to sit on the other side where you’re interviewing candidates. Some candidates will get stuck on arguing some irrelevant point or trying to fight against the interview question for too long in an interview. Once you see how much it hurts the interview process you learn to never do it yourself.
I went to law school and a few of us students were engineers. For our first set of essay exams, the professors all instructed us to "just answer the legal question" and not include extra analysis. After the exam, many of the engineers didn't do well because the professors *actually* wanted you to weave the whole sylabus into your answer (i.e., discuss hypotheticals that were not actually part of the question asked), not just answer the question. After that, we were fine.
This is also what I learned the hard way. In many situations the customer doesn’t say what they really want. There are a lot of reasons why. I usually have to write down a lot of hypotheticals. If X is the primary concern, we should do Y. If U is the issue, we should do V.
I wouldn't expect customers to say what they really want. They are looking for faster horses after all. But law professors? Among all professors, law professors should be the ones saying what they really want.
The point is that you’re supposed to kiss clown’s ring and do the dance.
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?
Right? I'll often structure interview questions like this. I give a basic problem, hoping for a basic answer. Then I add complexity, seeing how they respond.
In my experience, it's much easier to train somebody on how to scale a basic system up in response to need than it is to get somebody who favors complexity to cut it back.
> neurodivergent people in our ecosystem who would trip up on that question just because of how it's framed
If anything, it's neurodivergent interviewers. If I insisted on a different design I'd either ask a question that's not solved by "just use postgres" or follow up with "ok, that would work, but what if <something that would prevent postgres from working>". Just failing a candidate for a correct answer is a prime example of why interviewing is so bad.
It's probably more about your mindset, than about being neurodivergent vs. neurotypical. If you care more about maintainability and operations, there's a whole host of solutions you'd never built.
if your brain short-circuits at ambiguity, or you're completely incapable of understanding intent and you take everything literally, that is a negative hiring signal.
> 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.
To be fair, the simple answer is not so simple within Google.
The issue is that Google achieves reliability by insisting on n+2/n+1. Globally your service is in at least 2 more data centers than is required for full load. In each region in at least 1 more data center than is required for full load.
If you're using the Google toolchain, all of the scalability and fallover problems are automatically handled by the layers that you're relying on. Which everyone expects you to use, because they are already integrated into the environment.
But if you go to use Postgres as a data storage layer, then you also need to take care of replication, failover, backup, and make sure that this is integrated with the automated systems that Google already has to detect when this is needed. Even after you've done that, people from outside of your team will need to be convinced that you've done that. Simply because you're doing things differently, you'll get extra scrutiny.
As a result, even if Postgres would have worked perfectly well, it is usually not the optimal answer for someone who is working within Google's environment. Don't think of it in terms of, "Does this do the job?" Think about it in terms of, "Can those in the broader organization easily certify that this does the job?" That certification is easier when you use standardized parts that are themselves already certified within the organization.
My guess is that your interviewer was aware of this. And was left with, "What about that question that I didn't think to ask you about?"
If you're interviewing at Google, the expected answer to the interview question can't be to use Google's internal tools. "Use Postgres" is the standardized, understandable answer for anyone outside Google who needs to solve Postgres-shaped and Postgres-sized problems.
FWIW, that was the second time I interviewed at Google. The first time, which resulted in strong yes across the board at L7, the first system design was to design Youtube Video Upload. The second was a more practical problem about replacing a high-volume logging component where correctness was critical but environment was space-constrained (i.e. no ability to run old + new in parallel).
Those were my favorite system design rounds ever, thanks to the problems being interesting and the interviewers also being very dynamic. It was also pre-Covid, so it was just awesome whiteboard design sessions.
sigh I miss in-person interviews.
This is just an indication that it's a poor interviewing technique. If you ask a question expecting the answer to be predictable then you had better cover all possible ambiguity in leading the candidate to the answer you want to hear. But then you're no longer asking the candidate to be creative, are you? As an interviewer I might be more inclined to allow such an answer and then follow up with questions of my own to test the limits of the candidate's knowledge of and confidence in Postgres as a technical choice for serving all the different constraints of the problem space. This way either I discover how well-reasoned the answer is or else (for a good candidate) it prompts them to adjust the design to better fit the problem. In no case would I expect they need to fit their answer into some key and then scold them for not playing along with my imaginary game.
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.
On the one hand, interviewers can suck. They can be uninterested in understanding and embrace instead the role of a trigger-happy interrogator looking not for a good response - something that may very well require effort and considering new ideas on the part of the interviewer - but an excuse to cross you off the list. The interview begins to look like a game of "Guess what I'm thinking". Interviews should simulate a colleague asking you for help.
On the other hand, interviewees can give poor answers with no explanation. The interviewer should press for an explanation in those cases, of course, but perhaps some are trying to see if the interviewee instinctively provides at least some basic rationale behind the answer without having to be prodded each time, in which case it is a matter of communication habits and skills. Communication is essential, and it is under-emphasized and under-taught in so-called 'STEM' curricula.
> 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?
That was what I felt too. Why even need an interview for an acquihire when you have a direct link with the founder/CEO?
To maintain the illusion of meritocracy
> yes you might be right but you also understand what the point of the interview is
To make the interviewer feel smart and powerful? To hire people who will do the thing the boss wants whether or not it makes sense? To find people who will overdesign things to maximize resume impact and the ability of their bosses to talk about what sophisticated systems they're running and for which they therefore need a much bigger budget?
> 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.
Great example, and a lost opportunity in the interview---they should have asked "What are the requirements that would invalidate this answer? and what would you design if the requirements were changed in this way?". Maybe even "how long is the runway for your Progress solution if we consider future scaling up of the requirements"
Let me guess: the point of the interview was to see if he was a "team player".
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.
Sorry, I didn't get it. What was the 'right' answer?
Apparently some combo of kissing the arse and reading the mind of the interviewer...
It depends on the situation.
Sometimes you just have a bad interviewer who is looking for something specific from you but isn't telling you. If you're experienced in these interviews, you catch the signs and adapt by asking questions to suss out which direction the interviewer wants to take it.
Sometimes your answer is plausible but the interviewer wants to see you justify it. Sometimes your answer is wrong but the interviewer wants to see if you can reason your way through it, and maybe come up with an alternative.
If you're junior/inexperienced, it's often hard to tell and it'll feel arbitrary/unfair, and unfortunately that's just how it goes. As a more senior/experienced candidate, you can often figure out which situation you're in by asking questions to feel out the interviewer and then try to pivot during the interview, though it still takes valuable minutes out of the interview that you could have otherwise spent showing your competence.
"Postgres, because..."
They want a conversation to see how you think, not an actual answer.
Which is stupid, because they asked a question that the person didn't need to think to answer. So they didn't get to see them think.
nosql on serverless
distributed virtual abstract factory
You need the StrategyFactory in case you need further variances to the Factories you're making.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Completely idiotic on the part of the interviewer. Failing somebody for a correct answer - what a waste of everybody's time. If you want the candidate to pursue a particular technical path, tell them to do so while they're there in the office.
That is why they say, as a candidate, you are also interviewing the company you would be working for...
> 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.
My read of the story is that the decision to hire was already made, the interviewer goofed but was then set on the right track by his boss.
The question was bad if using Postgres would really be a better solution than designing and implementing a bespoke system, under the stated constraints. Either they should provide a better problem statement, or at least immediately follow up with “okay, suppose you can’t make use of an existing system like Postgres for $reasons”.
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.
If the numbers can be satisfied by a Postgres then thats the correct answer. The interviewers fucked up, because they sized the problem wrongly.
This is the same issue that was prevalent when the industry switched from HDD to SSD: some system design questions suddenly became trivial, because the IOPS went up by magnitudes. This is not a failure of the interviewees, who correctly went with the times, but a failure of the interviewers.
What kinds of system design questions got destroyed?
The correct answer is “Postgres would handle it, but if it needed to scale even higher, I’d…”
The point of a system design interview is to have a discussion that examines possibilities and tradeoffs.
And people weeded out by this kind of questions are probably rightfully so. I for one could not ever work with someone that says "my answer is correct, period.". Part of the answer and the discussions made by mature individuals must ask for feedback, incorporate it in your design, be open to compromises sometimes but also to die on a hill when it makes sense. And in an interview context, you ought to show the hiring manager all these faces.
Then, there are hiring managers that suck and you might be discarded because you didn't follow the script. Sure, but that's a bullet you dodged.
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.
Well, yes, doing the interview again is the right choice.
> 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.
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 ?
> The point is show how much you know and how smart you are.
I like that this sentence can be read both as a productive, well-meaning view on interviews, as well as a highly cynical one.
Also makes me wonder if the person will keep showing how much they know and how smart they are after they are hired, and if that is a good thing.
The point is the interviewers are sometimes obtuse.
Sometimes the point of the interview is to see if the candidate knows an existing solution and "just use postgres" is the good answer. Sometimes it's to test the technical chops and pretending postgres doesn't exist is the point.
The candidate shouldn't be expected to always guess right, unless the position says "a psychic". The interviewer should notice if the candidate is solving the wrong kind of problem and nudge them in the right direction instead of punishing the candidate for the wrong guess.
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 best way to get promoted at stripe is just self-marketing and social manipulation. Good engineers are leaving meanwhile tecnical leadership is being replaced with designers and marketers. Internal performance metrics are heavily manipulated as well. Patrick has completely surrounded himself with extreme sycophants at this point - he has no idea what is actually going on in his company beyond curated metrics produced by manipulative sociopaths.
Patrick Collison sounds like a lovely, trusting, scientifically-minded man who needs to learn the constructive power of destruction. The power of rage and contempt for bad solutions and bad communication (regardless of intent).
With a smiley face front-end, of course. Wouldn't want to seem not-nice!
Agreed, I really like Patrick - he is smart, humble, hardworking and trusting. But his kind and trusting nature is being aggressively exploited by some truly despicable people.
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.
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.)
“There’s no right answer we just want to see how you think” is gaslighting if there is a right answer and wrong answer.
This should go straight to the DOL, EEOC, FTC and other bodies as some form of abusive labor practice that excises it from the employment process under threat of economic sanctions
I remember getting a test, in an interview in the 1990s, where I was asked to design a set of gates (ICs) to do some binary maths (Division, multiplication, etc). The input was an 8-bit set of leads, and the output was an 8-bit set of leads.
I looked at the formula, and drew two wires, connecting a couple of the leads from the input, to the output.
I was offered the job, but ended up declining it.
Ha! I just had a debate about this with my friend. A certain ferry company uses a big Google Sheet to track where all of its vessels are currently docked in their home port, as well as which employee is assigned to which vessel for the day, etc (it's very information dense with color coding, and employees check it daily to get their vessel assignment). My friend thought this was completely unacceptable for a big company, and that they should build a bespoke software for this purpose. I think that it was a brilliant idea to use Google Sheets, it already solves all of the difficult problems and obviates the need to have an inhouse software development team or an expensive contract. I buried my hubris deep underground
As a teenager I worked at a company that rented rafts for a short trip down a river. We’d take the rafts from the customers at the end and truck them back up to the start. As they became bigger and busier, it became more important to keep track of the status of rafts and know when they were going to be getting back to the top.
They paid tens of thousands to have software made for this purpose. It sucked and was totally unable to handle the simultaneous realtime access and modification that was required.
They knew I was good with computers, so asked me if I had any ideas. In about an hour I made them a Google Sheet that worked great for the next several years until I left.
I've just spent a few weeks making a tool in our software to replace a complicated google sheet, and it was surprisingly hard. I think the most important thing was that our designer really figured out what the tool should do. If we've just replicated what they have and made a columnar editor of sorts, we would've just made a less flexible tool for them. But in the end, we made something not even resembling what they had, but which actually solved the core issue, and I think that's important.
And when you take away their sheet, you better be ready to support them. If they need to track new data, they could just add a new column in their sheet. Now they have to talk with tech. If tech blocks operations, they're quickly back to their sheets. The tool made by tech should be an enabler, not something to force compliance or whatever.
Sheets are so, so flexible. This can be really hard to replace. At the same time, they're also brittle with little system support. Like the example above, what if you assign someone not working that day to a boat? Or accidentally put two boats in the same location? Lots of small issues that proper tooling could handle, especially when backed with more data inside the system.
What made the operators happy to use my tool in the end was that they didn't have to punch so many numbers. They would copy paste numbers from various systems into their sheet every hour to keep track. The tooling pulls it in real-time.
So we replaced this one sheet, because it would help them a lot. But their other sheets we're leaving untouched for now. Nothing to gain by moving them. So judge each sheet individually.
My startup used Google Sheets as a CRM until we discovered there’s a 3 million row limit (by running into it) and had to build something else. Sheets is amazing. Don’t forget to lock that first header row, though.
I'm there with you... maybe, maybe using the sheets API to create a simpler front end for very specific use cases, like an individual seeing their assignment for the day, or maybe texting everyone that info.
As much as people will rely on databse (rdbms/sql) backed applicatons, in the end a lot of the business world runs on spreadsheets... Not only that, but excel, and I'm assuming plenty of others have integration points for pulling data from other resources... Spreadsheet masters can do very impressive things with what appears to be a simple tool.
I've seen suppliers using google sheets for a list of tens of thousands of items. Also color coded and filterable and what not. It worked. I could access it programmatically, I had no complaints. (Especially with an experience of some of these suppliers having shitty hosts and shitty platforms and their massive XMLs taking forever to load.) Then again I'm sure I would speak differently if someone just decided to rename a column randomly :D
We have no idea if its a good solution or not. It depends upon, among other things: how long it takes to update it, the error rate, and how acceptable those errors are.
All fun and games until an Intern deletes the original sheet or fatfingers critical information.
I think the correct answer would be to ask "why are they doing that and not using Google Sheets?".
There are a lot of good reasons for not using Google Sheets. Maybe the spreadsheet is using features that Google Sheet doesn't support, maybe one of the parties is in China, where Google services are blocked, maybe it is against company policy to use Google Docs, maybe they have limited connectivity.
It is good to acknowledge the obvious, off the shelf solutions, but if you are given a job, that's either because the customer did their homework and found out that no, it is indeed not appropriate, or, for some reason, they have money burning their pockets and they want a custom solution, just because. In both cases that's how you are getting paid. So, I don't consider "use Google Sheets, you idiot" to be an appropriate answer. Understand the customer specific needs, that's your job, even more so in the age of AI.
And maybe the interviewer will be honest and say "just assume you can't, this is just an exercise in software architecture".
> 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.
To give you the inverse perspective, an OG blogger named Steve Yegge made a list of five essential phone screen questions:
https://sites.google.com/site/steveyegge2/five-essential-pho...
Question three is this:
Last year my team had to remove all the phone numbers from 50,000 Amazon web page templates, since many of the numbers were no longer in service, and we also wanted to route all customer contacts through a single page.
Let's say you're on my team, and we have to identify the pages having probable U.S. phone numbers in them. To simplify the problem slightly, assume we have 50,000 HTML files in a Unix directory tree, under a directory called "/website". We have 2 days to get a list of file paths to the editorial staff. You need to give me a list of the .html files in this directory tree that appear to contain phone numbers in the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.
How would you solve this problem? Keep in mind our team is on a short (2-day) timeline.
In Yegge's case, he explicitly does NOT want a hand-written program, he wants the candidate to suggest a CLI tool, e.g.
grep -l -R --perl-regexp "\b(\(\d{3}\)\s|\d{3}-)\d{3}-\d{4}\b" > output.txt
———
So...
These questions aren't good or bad unto themselves, but when the person asking is engaging in "Guess the answer I'm thinking of," don't beat yourself up if you guessed wrong. Your answer might be prized by someone else with an enormous amount of experience hiring engineers.
At AWS, a team asked for help maintaining a bespoke internal Java service that diff'd json for manual reviews.. replaced it with a jq one-liner
A former coworker was evaluating the cleanliness and structure of some non-free GeoIP data that took the form of several large CSV files. He was writing nested loops in Go that parsed the CSV and evaluated the predicates that interested him, and it was arduous and not going as quickly as he would like.
I told him to slurp it all into a sqlite database and to express his data integrity questions as SQL queries.
It was still a pain in the ass for him, but leveraging that tool made things go a lot better.
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.
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".
I attach a copy of the file and then provide a network location for where it is located. Makes it easy for people to just open up a simple copy to look at it and they know where to go to access the original.
I've stopped playing the game of 'guess what the right answer is'
I would have said the exact same thing and pushed the interview to consider 'why are we creating a tool when something off the shelf solves our business needs? What kind of runway and resources do I have to meet this goal? What is good enough for our problem here? Do we want to expand our scope to enable external data integration and downstream data consumption"
You will find better employment outside the circus, possibly even selling to the circus
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.
Is it? I have long thought that most things business people are using a spreadsheet for belongs someplace else. They are easy ways to run quick what-ifs or make lists, but generally the right answer is update the system so they don't need a spreadsheet. If the data is financials - why can't your accounting system give everyone the view they need from the shared system? Othertimes what they really need are a database to track this. But a spreadsheet is easy and so they ignore all the problems it creates because it needs a real engineer (and often more money than they can spend) to create the right solution.
> it needs a real engineer (and often more money than they can spend) to create the right solution.
Then it's the wrong solution. Period.
There are plenty of annoyances with spreadsheets, but part of what makes them so robust and powerful is that they don't take a ton of specialized knowledge, and they remain incredibly flexible.
An expensive, complicated, static, "right" solution for a small business is folly (honestly - this stays true up to medium/large business). It's a ton of time and energy focused on the absolute wrong thing. When a spreadsheet can reach the same result in a fraction of the time.
Especially given the result may not actually be that important, and they pivot to something else entirely in the very near future.
I've worked at several startups. I'd caution even software startups from assuming that custom solutions are the right approach. They usually aren't. They're a waste of time and effort that ends up saddling you with a brittle, expensive solution designed to solve problems from last year.
You are missing something: how much is spent because the spreadsheet isn't the right solution - nobody measures this (or even knows how). How much are you risking because spreadsheets are not robust - when will a mistake catch up, and what will be the cost? There is a reason accountants use double entry bookkeeping, and spreadsheets don't have that.
Nobody has the money to spend doing things right unless they have been burned. That doesn't mean the money shouldn't be spent first.
Spreadsheets are powerful I will grant. However they are not robust. A robust system works very different and includes features (like tests) that your spreadsheet doesn't have (I don't if it could have them, but it is safe to guess they don't)
I didn't quite mean it that way. My question is basically asking "Does this hammer know that not every problem is a nail". To give a specific answer to your question, my accounting system is excel, and "everyone" is me. There are definitely plenty of places where a database makes sense. But it's also important for database engineers to understand where databases don't make sense. It's kind of like that old problem we had where people would keep on saying "We can do X with blockchain" and the typical answer is "ok but that's worse".
Well, you've long thought wrong.
Argh gawd I hate this!
There are plenty of reasons that a department within a company will prefer spreadsheets. Software is not the answer to everything and also this is the same problem you get when Microsoft introduces those pesky 'Power App' developers etc or previously the Sharepoint 'web parts' etc....essentially someone who kind of feels they are the 'owner' of some information then decides to formalise the process in their own little way.
Now you have a person wasting a bit of time making their little tool but you've also got people complaining that someone's now essentially taken control of it etc. At a former employer our procurement team used spreadsheets to track basically everything but importantly everything on our PCBs - every single component and their suppliers and prices etc (various factories around China usually). This would have been a horrible thing to try and formalise in a web app just because of how often they were all changing their own conventions etc (often suppliers changing what information they gave to them, too). It would have been a wild goose chase to formalise it and more than the trouble it would be worth.
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.
I just wish that in those cases the interviewee gives feedback and allows you to rewrite instead of just failing you. I mean in practice nobody writes library functions themselves unless absolutely necessary, but I get that for some positions you have to demonstrate that you can write lower-level code if you have to.
I think that it was probably a poorly designed question, but surely you could throw the interviewer a bone by giving a custom answer after they reject the library.
I love how your answer was straight, to the point and leverages existing standards, then scrolled up to the question and had to go through someone else's thorough, multipage response. Full marks to both answers!
I do absolutely love the other answer!
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.
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
Not an engineer but reminds me of a similar situation I've seen interviewing
Sometimes we'll ask market sizing questions. We will say it's a case question, it's to see their thought process, they're supposed to ask questions, state assumptions, etc.
Occasionally we'd get a candidate that just doesn't get it. They respond "oh I'd Google that". And I'll coach them back but they just can't get past that. It's about seeing how you approach problems when you can't just Google the answer, and we use general topics that are easily accessible to do so. But the downside is yes, you can google the answer.
I wouldn’t be surprised and most likely would go for a walk :)
I would ask, why are they emailing it? Maybe there's a good reason they can't use sheets.
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.
Maybe you were supposed to identify what business need they were trying to solve and see if there was anything better than a spreadsheet?
Spreadsheets are a tricky one some people like the power and automomy they have with spreadsheets.
But more often spreadsheets are the only way to transfer data between solos and it wastes a lot of time and is error-prone.
It really depends on how much time is spent filling out the spreadsheet.
If they are collectively spending 1hr/mo on the spreadsheet then it’s not worth an SWE’s time to optimize it. If they are spending 4hr/day on the spreadsheet then it’s a prime candidate for automation.
It depends sometimes it's currently 1hr/month but more frequently and a dashboard would add value to the enterprise.
I feel like you could start waxing poetic about engineering value of meeting people where they are, not reinventing the wheel, etc.
Then after a brief discussion of that you could actually ask if the purpose of the question was for you to design a system to handle that situation and jump into the design.
The awkwardness after your answered was the interview telling you something important. A team that penalizes picking the right tool over an impressive one is a team where you'll spend years creating complexity nobody needs. The lesson isn't "next time pretend Google Sheets doesn't exist." It's that you found out early what they actually reward.
The annoying thing about corporate hiring practices is – speaking from experience – some of us would have loved your answer. But then it goes to committee and someone's like, "this iOS engineer doesn't know any javascript, and I'm an expert in javascript, so I'm a 'no'."
Remember you're interviewing them just as much as they are interviewing you.
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.
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.
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.
> The point is to understand the candidate's thought processes
The problem is that this is a 2-way street. The candidate is forced to guess the interviewer's thought process, because otherwise they may be pitching over the interviewers head.
We have to spend a ton of time calibrating hiring loops for this, because otherwise you get staff level candidates being failed by mid-career interviewers who don't understand the full context of the question they are asking (and hence don't understand why a staff eng solves it differently than they would).
I think you could start saying that there are multiple options. The simpler is sharing the sheets in Google (or Microsoft) Sheets. After this, Then, I would have asked if there are any security and/or compliance issue to doing so to analyze other alternatives.
I would have said "Move them to Google Sheets, but I gather from the nature of the question this is about finding a solution to build from an engineering standpoint..." and then go into ideas for how to collect user research, and apply those findings to a new tool build.
"I'm sorry, you're overqualified for this role"
Yours was a clever answer to a stupid question. Tech interviewers need to leave college behind and start treating candidates as professionals. Puzzles, white boarding and riddles are unique to software engineering roles, you would never see a lawyer, an accountant, a doctor, or engineers in other disciplines going through any of this nonsense. These methods are proven to be a poor predictor of job performance. In my last role as lead engineer we would chat with the candidate over lunch about random topics. We first wanted to see if they would fit our team. Then in the afternoon let them work in a little project that was actually part of active development. This way we discovered that most candidates who went through the screening process could actually be pretty good team members. Our issue was having to decide who to give the offer to, while other companies keep rejecting candidates over bubble sort. Our attrition was also pretty low. So it happens that software engineers will surprise you when you treat them as grown ass adults. Who would have guessed?
Honest question: did you really not read the room there? I mean, if I were on the interviewer side, asking that question, and getting an initial answer "Well, to be honest I would tell them to use GSheets because given the current situation is the highest benefits/costs solution, but for the sake of a system design interview I would also think about designing a bespoke internal solution that would use blah blah blah". You would get a "strong hire" evaluation and you would still be able to turn down the offer if you wanted because that question might have been a red flag to you.
Did you get the job?
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.
Run or email their seniors and ask them if they're hiring for higher-up positions.
But this is connected to another thread on HN about engineer/manager titles and how they basically have no value if you try to compare them between employers.
Or maybe this: https://news.ycombinator.com/item?id=47247719
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.
I mean that's not really a good answer because you need to ask why they are sending a spreadsheet back and forth. Like yeah using a shared spreadsheet saves them having to email back and forth, but it doesn't help formalize the process, include validations, or make the data available to other systems. And maybe it would turn out that none of that is actually helpful in this case, but if you don't make an effort to ask and understand what's going on then you won't know if there's some bigger problem that needs addressing.
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.
> 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.
People on call will use AI as well. As long as the first AI left enough documentation and implemented traceability, the diagnosing AI should have an easier time proposing a fix. Ideally, AI would prepare the PR or rollback plan. In a utopia, AI would execute it and recover the system until a human wakes up.
Or at least there is something to chat with about the issue at 3am.
> In a utopia, AI would execute it and recover the system until a human wakes up.
in that utopia, the on-call guy doesn't have a job
This. I've been a sysadmin for a quarter of a century and have professionally written next to no software. I've debugged every system I've had to support at some point though. It's a very different skill set.
True, but I think the implication (as I read it) is that AI may be providing more complex solutions than were needed for the problem and perhaps more complex than a human engineer would have provided.
it's MUCH worse now, not just because of the massive amount of code generated with zero supervision or very little supervision, but also because of the speed at which the systems grow in function
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, or you use money to buy a tool that solves that problem, well then it's still your job to solve that problem regardless of which tool you use.
But given how poorly bought software tends to fit the use case of the person it was bought for... eventually generate-something-custom will start making more and more sense.
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. Overall I think it'll be an improvement because there will be less distance (both in time and along the social graph) between the software's user its creator--them being most of the time the same person.
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.
It reminds me a lot of people who take Code Complete too seriously. "Common sense" is not an objective or universal statement unfortunately - plus, speaking for myself, what I consider "common sense" can change on the daily, which is why I can't be trusted adding features to my own codebase long term <_<.
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
Awesome! However, the corporate is excited with using AI, making the coder the one who's at risk at getting fired for writing the exact same lousy (for the sake of the argument) code.
Or worse: for not relying as much as possible to the AI who apparently can write just as bad code but faster!
A subtle detail: you speak of coders, not software engineers. A SWE's value is not his code churning speed.
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.
Please let's stop with the "but some humans also suck at this so it's ok if LLMs also suck at it" argument. It doesn't add anything to the discussion.
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"
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"
instructions.md is the new intern.
Maybe a better way to handle "minimize cyclomatic complexity" would be to set an agent in a loop of code metrics, refactor, test and repeat.
Good idea. Am still a bit shy around token budget spend.
This seems like a perfect use case for a local model. But I've found in practice that the system requirements for agents are much higher than for models that can handle simple refactoring tasks. Once tool use context is factored in, there is very little room for models that perform decently.
What I hope to do with refactoring is to distill namespace and common patterns into a DSL. I am very curious about what tradeoffs you found.
Whatever agent I tried would include thousands of tokens in tool-use instruction. That would use up most available context unless running very low-spec models. I've concluded it's best to use the big 3 for most tasks and qwen on runpod for more private data.
I think this is at the moment the practical limitation to using AI for everything (and what the coding agents themselves also optimize for to some degree, or it's the slider they can play with for price vs quality, the "thinking" models being the exact same, but just burning more tokens).
Am waiting for the next Mac Studio to come out to experiment with the "AI for everything" approach. Most likely, the open source distilled models will lower quality. So, another "price vs quality" tradeoff. Still, will be fun to code like I'm at a foundation lab.
This is something I keep thinking while coding with AI, and same with introducing library dependencies for the simplest problems. It’s not whether how quickly I can get there but more about how can I keep it simple to maintain not only for myself but for the next AI agent.
Biggest problem is that next person is me 6 months later :) but even when it’s not a next person problem how much of the design I can just keep in my mind at a given time, ironically AI has the exact same problem aka context window
Well in 6 months it you and a 6 months smarter LLM.
There's also the operational cost of running whatever is churned out. I wouldn't exactly blame that on AIs, but a large contingency of developers optimize for popular tech-stacks and not ease of operations. I don't think that will change just because they start using AI. In my experience the AI won't tell you that you're massively overbuilding something or that if we did this in C and used Postgresql we'd be able to run this on an old Pentium III with 4GB of RAM. If you want Kubernetes and ElasticSearch, you'll get exactly that.
Was this comment written by an LLM? It has a lot of the tell-tale signals, and pangram gives it a 100% chance of being written by AI.
> When an agent can generate a "scalable event-driven architecture" in 5 minutes
Currently they can't. Anyone with a basic understand of sw engineering will find numerous issues with the result of such a prompt within minutes.
But the product manager who asked for it won't realize that.
Unless you hire good TPMs!
AI generators only generate that if you tell them to though - as a developer (especially senior) it's your job to know what you want and tell the AI coding tools that.
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.
Thats the kind of thinking that got us into this mess... scab
The "coding benchmarks" should be based heavily biased on what dependencies they use etc. Reduced characters etc.
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.
There's different kinds of abstraction. There's abstraction like Jackson Pollock and there's abstraction like what Dijkstra as suggesting: elegance. Which personally made the article a very weird read to me
tbh codebases like that predate AI code generators. I had one job where my predecessor was not a very good developer by modern standards, but he was productive... a dangerous combination.
I also kind of respect it, it bothers me endlessly when everything isn't perfect and this guy just threw caution to the wind. Jokes on me as I'm working for him now. But it's not like anything that predates AI, I couldn't write this type of slop if I tried lol. Zero formatting, linting, or anything. Just straight goulash.
What is the maintenance cost when Opus 6 or whatever is available?
Agree but I wouldn't say it's subtle, the slop builds up quickly
I feel like the article is conflating simplicity with minimalism. Just doing the minimum of whats asked isn’t in itself enough to differentiate great vs ok.
Simplicity is worth recognizing only when the person started with a complex problem and ended up with a relatively simpler solution.
For a straightforward ask you will have people who will just build a hut and another will build a campus, who is right really depends on many factors and time.
Ironically, this article is "over simplifying" the problem.
In the FAANGs I've worked at, engineers who come from scrappy companies and implement hacks (Like the example of emailing spreadsheets around) undermine the business and will cost the productivity of thousands of people.
However, at the startups I've worked at, the folks from big companies that try to implement a super complex thing (e.g. exotic databases, overly ambitious infrastructure) The results are equally catastrophic for a company attempting to bootstrap when the complexity is so far removed from their core business.
What makes an experienced engineer is recognizing both states, understanding what works where and making the right trade-offs, usually from experience you can't fake your way through. I've seen a lot of projects that took 10-20 engineers 18 months to so we could sell something that landed a $100M contract with a customer. You see that enough times and you won't bias as hard against complexity. But of course it's situation dependent, like anything.
There are definite discontinuities in there. What works for a team of 5 is different to 50 is different to 500.
Even just taking fault incidence rates, assuming constant injection per dev hour...
Being able to project manage yourself is indeed a very difficult skill
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.
They're still giving out the "Just Do It" award
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 confess I assumed that the spirit of that award was more in "using what you have" than it was in making a simpler solution? They definitely over indexed on how clever the door desks were, though.
It is funny how much people assume quality from appearances, though. Same for costs.
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.
One of my the papers I share around a lot is "Nobody ever gets credit for fixing problems that never happened (2002)"[1]. I like it because it's not purely about software so the examples resonate better with some exec level people in other teams I work with.
[1]https://ieeexplore.ieee.org/document/1167285
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.
Except it's not something you can really accurately assess before you start working somewhere.
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.
Measure no, but only engineers care about that (and I'm not even saying that they're right, engineers care a whole lot too much about hard data). You can show alternative solutions, estimate, make assumptions, even make up numbers and boom, you have "data" to show you improved things. You don't even have to lie: you can be very open that these are assumptions and made-up numbers, that it's just a story, what's important is that people come out with confidence that thanks to you, things are better by a bit/a lot/enormously.
You can. GitHub is about to hit zero nines of uptime[0]. But feedback like that is far too late to be useful. Maybe (principal or senior) engineers should be the ones to judge, and be trusted by management that their foresight is worth pushing the deadline?
[0]: https://mrshu.github.io/github-statuses/
You can't. You can hypothesize about the counterfactual in which you shipped a "steaming pile of complexity," but you definitionally cannot measure something that does not exist.
Won't that show up in roi numbers?
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.
I've found simplicity rarely earns promotions because it's invisible on a P&L and executives respond to hard numbers. In one role I converted a refactor into a business case with a 12-month cost model, instrumented KPIs in Prometheus and Grafana, and ran a canary that cut MTTR by 60% and reduced on-call pages by two-thirds. Companies reward new features over quiet reliability, so slow feature velocity for a quarter while you amortize the simplification. If you want the promotion, make a one-page spreadsheet tying the change to SLO improvements, on-call hours saved, and dollar savings, then own the instrumentation so the numbers are undeniable.
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.
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.
Thanks for the sane take. This article is engagement-porn for every engineer who ever looked at a system they didn't understand and declared they could do it much simpler. It's not because people love to promote complexity-makers, soothing as that thought might be.
Never seen these metrics in real life, especially in engineering.
"Code footprint is 80% more efficient / less"
(when there is a simpler design over more complex "big ball of mud abomination" in contrast)
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.
Except when one of the criteria for promos is "demonstrates complexity". Then you results do matter, but you don't have the "complexity" box checked.
And mostly these numbers are made up BS. But management will eat them up.
> "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.
Yup.
As a manager, I preferred engineers that delivered simpler code, but I also ran a team of experienced, high-functioning coders. I suspect teams with many less-experienced people get The Parable of The Toaster[0].
[0] https://www.danielsen.com/jokes/objecttoaster.txt
I'd add one point to this, as someone who voraciously fights against complexity at every turn, more and more as I get older. I've experienced times where leadership/management will assume that you're fighting against the complex solution simply because you don't grasp or understand it. It's irritating at best.
The longest lived projects and solutions I've worked on have always been the simplest, easiest to replace solutions. Often derived from simple tests scenarios or solutions that just work and get shifted over without much re-work.
What's somewhat funny, with this is that AI code assistants have actually helped a lot with continuing this approach for me... I can create a stand alone solution to work on a library or component, work through the problems, then copy the component/library into the actual work project it was for. I'm in a really locked down internalized environment, so using AI for component dev is on my own hardware... but the resulting work is a piece that can be brought in as-is. No exposure of internal data/resources.
I don't think I'll have a level of trust to "one-shot" or vibe code solutions from AI, but leveraging the ability to spin up a project as a sample to test a component/library is pretty great to say the least.
To add to this, sometimes leadership will assume (or even imply) that there's some laziness involved in not wanting to jump immediately on-board with the complex proposal.
I often end up saying, "I can build this, and I will build this if product insists on it, but first let me suggest an alternative ordering of deliverables that starts with a simple implementation and moves towards this one." In almost every case, that simple implementation is still what's in production years later.
Lead time for "how long until we can start using it" is one that is hard for a lot of folks to really take into consideration. There are terms for this, "earned value" and such. I have rarely seen them used in such a way that the planning actually worked out, long term.
The only way to learn this lesson is the hard way
The example he gave where each dev gets a single feature done seems to skip over the opportunity that Dev A has - after she spends only "a couple days" on that feature to ship a simple solution, she now has the rest of that week to do another feature, and another... in fact, she could probably get 6 features done in the time that Mr. Complexity took to do his one feature (3 weeks in the straw-man example). Then the promo packet looks much better for Dev A - while it says "implemented feature X", it also says "implemented feature A, feature B, feature C...". Doesn't that seem more attractive?
Slightly related: I've noticed that there are lots of "ideas guys" (yes, guys) in our field who love to bloviate, and maybe even accomplish some stuff that looks really good. I have made a career out of just putting my head down and getting shit done. I may not have grand design ideas, and in fact have had to unlearn the "fact" that you need to come up with, and implement, Big Ideas. In my experience, people who "get shit done" may not get fancy awards, but their work is recognized and rewarded.
I think sometimes flip side is that the engineer looks like they just shipped a bunch of "small features" A, B, C... because the solutions were so simple
> in fact, she could probably get 6 features done in the time that Mr. Complexity took to do his one feature
Not if management is moving at the speed of the more complex solution.
> yes, guys
I thought that blatant sexism wasn't a part of this website.
> In my experience, people who "get shit done" may not get fancy awards, but their work is recognized and rewarded.
top kek
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!!!! req/sec
I've forgotten how to count that low.
I'm gonna need a Kubernetes cluster with a distributed database with a caching layer, RabbitMQ/Kafka/whatever, and...
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?
Wait, so you are telling me that not every company builds Spotify on design system interview? Impossible
AWS loop a long while back wanted me to design a playlist system so my dumbass brain snapped to m3u files or w/e people were using back then and designed a system to host/share playlist files. The teenager (ok probably in their 20s) interviewing me seemed more and more confused as we went on but he never tried to redirect me to what he really intended.
Most people forget that the early web was built in server closets on-site handling hundreds of requests per second. The business was sold hyperscalers because devs wanted more servers and were tired of arguing WHY they wanted more servers. Then they got sold on Highly Available services because every second you're down is a dollar, or more, lost. Nobody mentioned that the cost of building and maintaining it costs more than the money you'd lose except for the largest of organizations.
Don't even get me started on the resume-driven development that came along with it.
And maybe I'm completely wrong. This is a perspective of one.
Honestly I think that the real result of this is developers that don't really understand the underlying tooling and invent all sorts of bad architectures.
One common example I cite is at one job I owned Kafka and RabbitMQ clusters. Zero consideration was given to message size recommendations and we had incidents on the regular because some application was shoving multi-hundred megabyte messages into RMQ. They'd do other stupid shit like not ack their messages which would cause them to never be removed from local disk. This was a huge org, public company, hiring "only the best and brightest".
Management endlessly just threw more hardware at it rather than make the engineers fix their obviously bad architecture. What a headache. Some companies take the "prioritize engineer happiness" thing right off a cliff.
I 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.
I'm extremely cautious about complexity, yet have adopted a claude-based dev flow. It comes down to watching and guiding it, and not letting it run autonomously. At a certain point your codebase will tip over into the patterns you've defined and claude will recognize and follow them. Just treat Claude as a vim editor mode and you will see a big difference, and your relationship to the tool will change.
The only solution that I've found to work, somewhat, is to plan with it to design the APIs exactly how you want it, atleast the public facing ones. It still does all kinds of mess in the functions but those are easier to cleanup on the next iteration cycle. If you let it design everything, it'll definitely go overboard.
What about someone inexperienced but skeptical, using AI to learn + fix their own code before opening the PR?
That's an interesting question ... how should a less experienced developer use AI productively, and learn while developing? Certainly using it as a magic genie and vibe coding something you are in no position to evaluate is not the way to go, nor is that a good way for anyone to use AI if you care about the quality or specifics of the end result!
There's always going to be some overlap, wanting to use a new skill/library in a production system, but maybe in general it's best to think of learning and writing/generating production code as two separate things. AI is great for learning and exploration, but you don't want to be submitting your experiments as PRs!
A good rule of thumb might be can you explain any AI-generated design and code as well as if you had written it yourself? If you don't fully understand it, then you are not in a good position to own it and take responsibility for it (bugs, performance, edge case behavior, ease of debugging, flexibility for future enhancement, etc).
I very much agree with that, I had the same thought a few days ago.
I feel/am way more productive using chatgpt codex and it especially helps me getting stuff done I didn't want to get started with before. But the amount of literal slop where people post about their new vim plugin that's entirely vibecoded without any in-depth thinking about the problem domain etc. is a horrible trend.
Simplicity is hard. Mark Twain's 'I would have written less had I had more time' at the end of a letter comes to mind.
Software dev's tendency to build castles is great for technical managers who want to own complex systems to gain organizational leverage. Worse is better in this context. Even when it makes people who understand cringe.
You would think that things not breaking should be career-positive for SysAdmins, SREs, and DevOps engineers in a way it cannot be for software devs. But even there simplicity is hard and not really rewarded.
Unix philosophy got this right 50 years ago — small tools, composability, do one thing well. Unix reimagined for AI is my attempt to change that.
Relatedly, I'm periodically thinking about the issue of people who prevent problems not being rewarded as much as those who become "heroes" for resolving avoidable situations
I guess it may be important to underscore the value that simplicity provides over needless complexity or to sell people on the value of problems prevented rather than preventable catastrophes that were dealt with
Maybe we could encourage a culture of patting people on the back for maintaining reliable "boring" systems
Some people also crave "drama" so there might be a way to frame "boring reliability" as some kind of "epic daily maintenance struggle that was successfully navigated"
You’re thinking along similar lines as I am. The article talks about “visibility” in the end. This might be a document that is written. Or it could be a demo thats shared. Or a simple shout out in slack.
As engineers, we tend to keep away from the limelight and quietly get shit done and be happy with it. But professional growth and recognition requires visibility somehow. We need to be creative on how to achieve that.
The difference between the fire fighter and the fire safety inspector. The former puts out fires and saves lives and is of course a hero. The latter complains about things that never happen, wastes everybody's time and money and is generally annoying.
It seems like the safety inspector might be closer to a SOX compliance auditor or something... in this metaphor, the engineer who doesn't build something that "catches fire" is just the one who uses sensible materials, includes smoke alarms in the design, and chooses to use passive insulation in the walls instead of electric space heaters on a high-pile rug.
In my engineering job of over 30 years, I've noticed that the heroes that get rewarded for fixing the problems are usually the same ones who created the problems in the first place.
I've only been a paid-on-call firefighter for 10 years, but I have yet to work with any who are also arsonists. ;)
The name of the game is framing. You don't talk about simplicity, because most people don't really understand what simplicity is. They falsely equate it to easy.
Instead you talk about how you complete all your tasks and have so much bandwidth remaining compared to all your peers, the beneficial results of simplicity. Being severely under used while demonstrating the ability to do 2x-10x more work than everybody else is what gets you promoted.
In this vein simplicity is like hard work. Nobody gives a shit about hard work either. Actually, if all you have to show is how hard you work you are a liability. Instead its all about how little you work provided and that you accomplish the same, or more, than everybody else.
Exactly, simplicity is a subjective term; some think of it as in Clean Code where codebases end up as oneliner functions or overly formal lasagna code with many clean-feeling layers, but they can't see the resulting complexity in the overarching architeture.
Except you spend extra time making your code simple, rather than slapping together something that requires extra maintenance from the eventual owners.
Ideally we need metrics saying, "my projects require 30% less support or 50% less brainpower than comparable projects". Things like "average cyclomatic complexity", etc.
Simplicity is like any form of automation in that there is always an expensive upfront cost. The automation pays for itself by reducing time per interval, so its only a matter of when break even occurs as derived by the savings per interval multiplied by intervals in a given frequency.
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 agree. I generally don't ask "Do we need to future proof this?", I rather ask: "Do we paint ourself into a corner?"
For example, if you implement a job framework of things calling a REST API to do stuff async, a sufficient first implementation is a simple monolith doing the stuff and some retries or periodic calls. Because, if it does not scale, we can start thinking about replacing that with something to put things into queues and scaling stuff-doers horizontally and such. But often enough, these simple things scale quite the distance.
On the other hand, if you start introducing in-memory caches into a singular instance to taper around database performance... that's a huge issue. That always leads to pain.
Additionally though, I"ve started to keep notes about people doing simple, efficient things without fanfare. This way, if my boss asks me what Bob did over the year, I can tell them that Bob made these problems disappear and how Bob is starting to handle this area of topics more and more. Suddenly Bob is growing responsible for this area, and if my boss asks Bob about these topics they did well in an annual review, Bob can shine. Hope they learn though.
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
Ah, but it's worse than this. The truly ambitious ladder climber creates not just unnecessarily complicated abstractions, but organizations. Processes for people to follow. Infrastructure for people to maintain. Committees to vet changes. Standing meetings.
I actually got a job for deleting code. I was fixing a problem on a contract and noticed that I could fix the problem by getting rid of the section that contained the problem. The functionality could be provided in a much simpler way. Later the company created a position and I was given first refusal before they interviewed anyone.
It was a 8 bit embedded application in something like 10k of code. When I left I generated a short and clear explanation of why what I had done was awesome in terms of their future business ... because that is what you have to do if you work contracts. Which is the real message of the article. You have to write things up.
That sounds like good work & a good outcome. I think there may be one ingredient left though to this:
> You have to write things up.
...and someone has to read it who understands the value you brought by deleting complexity.
In my team, I've been working to help everyone do a task that's necessary, but because it was too difficult, people bypassed it. Over time, I made it simpler, others are joining to make it even simpler, but in the process, I'm not doing as many "feature tasks" as I could. I joke that people are mad at me every day, but grateful every week and month.
I had to stop trying to prove myself to the company. I have already done that when y'all interviewed me. Now I do what's best for everyone, and I want the company to prove to me that it deserves people who do the right thing despite the processes not valuing it. If it does not, I have enough resources to spend some time on the projects I cared about most.
This mentality gave me peace of mind and helped many people in partner teams go faster and with higher quality.
Management still does not openly appreciate it, but it shows in how they interact with me. Like when you learn to talk to your parents as equals. It's unexpected for them, but they quickly embrace the new interaction and they love it much more than the one before.
> 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.
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!
If every company I know does this, how am I suppose to make money?
There are reasons for "unnecessary" complexity. Mainly cost and time.
> 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".
Fair. I work on backend, and there we usually need db replication, sharding, event brokers, monitoring and alerting, autoscaling. I wish we wouldn’t need all of that, and could use a single server with sqlite… but that won’t cut it.
Malpractice is exactly the word for this sort of shit.
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.
>I think there’s something quietly screwing up a lot of engineering teams. In interviews, in promotion packets, in design reviews: the engineer who overbuilds gets a compelling narrative, but the one who ships the simplest thing that works gets… nothing.
I got emotional reading this. This is way too real.
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.
In full-time employment this is sad but true. There is a way out of this toxic loop however.
As a consultant/contractor I always evangelise simplification and modelling problems from first principles. I jump between companies every 6-12 months, cleaning up after years of complexity-driven development, or outright designing robust systems that anybody (not just the author) can maintain and extend.
This level of honesty helps you build a reputation. I am never short for work. I also bill more than I could ever as a full-time engineer based in Europe.
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.
There is a balancing point.
At core, complexity is derived from discovery of demand within those pesky complex humans.
Simplicity is the mechanism of finding common pathways within the mess of complexity of a product.
the tragedy is that simplicity is very expensive and beyond most organizations ability to support (especially since it can slow down demand discovery), and this is one of the allures of big tech for me. I was greatly rewarded and promoted for achieving simplicity within infrastructure.
That article made me chuckle.
I'm currently building a full-blown OpenAPI toolchain at work, where the OpenAPI document itself is the AST. It contains passes for reference inlining, document merging, JSON Schema validation, C++ code generation and has further plans for data model bindings, HTML5 UI...
Why? Because I'm working on a new embedded system which has a data model so complex, it blew past 10k lines of OpenAPI specifications with no end in sight. I said "ain't no way we're implementing this by hand" and embarked on the mother of all yak shavings.
I want all of the boilerplate/glue code derived from a single source of truth: base C++ data classes, data model bindings, configuration management, change notifications, REST API, state replication for device twins and more. That way we can focus on the domain logic instead, which is already plenty complex on its own.
I'm not designing all of this to be simple to develop. I'm designing it so that it's simple for the developers. Even with the incomplete prototype I have currently, the team is already sold ("you mean I just write the REST API specification and it generates all of the C++ classes for me to inherit?"). The roadmap of features for that toolchain is defined, clear and purposeful: to delete mountains of menial, bug-prone source code before it is ever written by hand.
Sometimes, it takes complexity to deliver simplicity. The trick is to nail the abstractions in-between.
This is the norm at large tech companies and, IMO, a huge problem and major detriment to productivity within organizations as the cost of that added complexity is paid by everyone.
BUT, at least very occasionally I have seen people get promoted for simplicity, I've even successfully made the case myself. With a problem that was itself so complex that it was causing fires on a regular basis, and staff & principal engineers didn't want to touch it with a ten foot pole. When a senior eng spent a couple of weeks thinking about the problem and eventually figured out a way to reframe it and simplify the solution, melting away months of work, making the promo case was actually quite easy.
The problem is, the opportunities to burn down complexity like that don't present themselves nearly as often as the opportunities to overcomplicate a thing, which are pretty much unbounded.
There's a related dynamic that I don't see discussed enough: simplicity is also harder to defend in design reviews because it looks like you didn't consider the edge cases. When someone proposes a three-table schema, the immediate question is "but what about X?" and the simple answer — "we handle X when X actually happens" — sounds like hand-waving compared to someone showing an elaborate diagram that accounts for every hypothetical scenario.
The irony is that the elaborate design usually handles those hypotheticals incorrectly anyway, because you can't predict real requirements from imagination. The simple version gets modified when real feedback arrives, and the modifications are cheaper because there's less architecture to work around.
Quite the opposite -- you get promoted for complexity and inefficiency, and pretending like you are the only SME who can handle it, thus creating a dependency between you and your manager. A good technical manager can see this coming a mile away. Bad ones don't but it costs the company.
The sad thing is that it is common to get fired when you make things better bc then your work is perceived as "done" and your skills are no longer necessary. There are countless IT job stories where someone delivers a technical solution that saves a company a ton of money or generates revenue, then they get fired bc the solution has been delivered and an off shore team has been hired to maintain the work.
Big corps suck.
Edit -- reading some the responses here on this topic and they are...eye-opening and depressing.
> 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?
That is very true. For whatever reasons - the bigger the company, the more unjustified complexity it cripples itself with without being aware about it.
Also survivorship bias is a very real thing (problem prevented is ignored, while problem solved is appreciated regardless of who and why caused it).
We've had an interesting experience on the interviewing side of this. Asking a system design question and getting answers involving multiple layers of caching, pub/sub, event-driven whatever/etc.. when the real answer is to just use postgres. It handles the scale we're asking about. We know it, as that's what we use internally.
I've only worked at my startup so I can't comment on scale elsewhere, but if our simple architecture can handle 30k requests per second, I think it can handle most other companies scale too.
If your interview questions answer is a particular technology then you're asking a really bad question.
There are two ways of constructing software: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
— C. A. R. Hoare
That's cute, but pure fantasy, imo. There's no non-trivial code that's actually used and maintained that's going to be immune to obvious deficiencies that get overlooked. Look at this [0], for example. Simple as can be, obvious defect in a critical area, left out in open source for ages, a type of bug an LLM would be liable to generate in a heartbeat and a reviewer could easily miss. We are human after all. [1]
[0] https://www.theguardian.com/technology/2014/feb/25/apples-ss...
[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC9436839/
The example in the story seems, if I may, "too simple."
Rarely have I seen an actually straightforward, simple feature that can be done in a day used as the basis to spin up a 3-week mini-project with a complicated new architecure.
What happens is a complicated-sounding feature is requested, and some devs will just take it literally and implement it, maybe along with some amount of "future-proofing" that logically follows because the spec is poorly scoped.
Other devs will spend some time thinking about it, realize that there is a really a simple requirement at the core of the request, and it only sounds complex because it was vaguely specified (or maybe these days an LLM was used to write the spec, and its vomit was copy-pasted verbatim). They just implement the simple thing that is the actual need.
This is one place where the agile/scrum practice of planning poker can help. You get a few smart people in a room, and discuss the story and its requirements. Hopefully someone will throw out a low number of points and say "isn't this simply asking for..."
Over my career, most of the complicated code I have written is no longer running. What is still running after 10 years? Postgres (or more broadly, a relational database). Fad frameworks or architectures come and go pretty quickly, they don't end up working as advertised, and it's on to the next thing. I no longer want to spend time in this hamster wheel churning out complicated code that will only end up as next year's tech debt.
Extends to the extreme levels of SaaS-ification of fairly basic app functionality as well.
It's often simpler to build something you know than to integrate a 3rd party service, but it's highly frowned upon by a lot of devs and management.
Auth and analytics are things I'm thinking of - we have good tools to build these in-house. Also just running a database - never seen so many people afraid of installing postgres and a cronjob to back it up.
I have a story about this; People had an HSM (in USB key form) which needed to be shared. The question came to create some elaborate piece of software for lending to prevent people from accidentally leaving it in their pockets and accidentally going home with it (which had happened a couple of times).
Instead I went to the hardware store across the street and bought the biggest (and cheapest) screwdriver I could find and attached it with some cord to the HSM. They never lost it afterwards.
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.
Maybe not promoted, but certainly hired, as a consultant.
Most of my engagements consisted of replacing politics-driven complications with simple solutions.
The bigger problem was first quietly showing all the affected people other interesting things that needed doing so they would let go.
And TBH, the simple stuff lasted the longest because it harder to misunderstand or misrepresent.
The structural problem is that simplicity accrues value slowly and diffusely, while complexity delivers visible credit immediately to whoever built it. The person who adds the abstraction layer gets the PR merged and the ticket closed. The person who deletes it six months later gets... a smaller diff and a shrug.
I've noticed the incentive breaks down even further when you consider that simplicity often means saying no upfront, which requires correctly predicting future maintenance costs that nobody has experienced yet. Complexity requires no such foresight. You just build the thing someone asked for.
The orgs where I've seen this actually work had explicit "deleted lines" culture, where removing code was celebrated as loudly as shipping features. Not many places do that. Most treat a 2000-line deletion PR with the same energy as taking out the trash.
Simplicity can be a powerful defence against complexity. When there are many ways something can go wrong.
Rather than trying to anticipate all the different failure modes one tries at first just to handle fact of failure itself, assuming there's no remediation.
If there's a way to make sure the worst case isn't terrible in some simple way then you do that first - like making a backup file or tr4ying to keep APIs idempotent so you can recover from issues and so on.
> Picture two engineers on the same team. Engineer A gets assigned a feature. She looks at the problem, considers a few options, and picks the simplest. A straightforward implementation, maybe 50 lines of code. Easy to read, easy to test, easy for the next person to pick up. It works. She ships it in a couple of days and moves on.
> Engineer B gets a similar feature. He also looks at the problem, but he sees an opportunity to build something more “robust.” He introduces a new abstraction layer, creates a pub/sub system for communication between components, adds a configuration framework so the feature is “extensible” for future use cases. It takes three weeks. There are multiple PRs. Lots of excited emojis when he shares the document explaining all of this.
So in this scenario two solutions are produced: Fast to develop but probably brittle (it is not described as robust, but it is described as easy to change), slow to develop but not brittle (but perhaps too complex and likely hard to change).
Both fucked up. Engineer A stopped too soon, and Engineer B built too much up before any value was realized.
You want Engineer C: Makes the fast solution that gives you feedback (is the feature worth pushing further? do users want/need it?), and continues to produce a more robust solution that won't crap the bed.
Engineer A is a potential chaos agent, tossing out and abandoning work too soon. Engineer B is a bottleneck who will waste weeks or months producing invalid solutions.
Go for the middle path.
In larger systems, what looks like “overengineering” can be deliberate risk management. In my experience, senior engineers do get promoted for simplicity but only when they can articulate the trade-offs and the future costs they are avoiding.
this is rare tho
You need the tension between both, or else either approach at most levels of systems, whether its an app or a corporation, tends to lead to toxic failures modes.
It could be something overbuilt, large organization structures. Brittle solutions that are highly performant until they break. Or products/offerings that don't grow for similar reasons, simpler-is-better, don't compete with yourself. Or those that grow the wrong way-- too many, much to manage, frailty through complexity, sku confusion.
Alternatively, things that are allowed to grow with some leeway, some caution, and then pruned back.
There's failure modes in any of these but the one I see most often is overreaching concern for any single one.
Maybe I am naive but I still believe that simplicity leads to personal wins in the long run. Having simpler system designs lead to velocity and eventually you become known as the "team that can deliver".
Or, the team that everyone takes for granted and/or the pointy-haired bosses assume their project must be pretty basic and anyone can do it.
But it frees up time to build more products, which could give you leverage for negotiating better pay.
The article's point is sound, but its missing a key component. People who build simpler systems are capable of getting more done - the build takes less, the maintenance takes less, etc. So when the engineer choosing simplicity is looking to get promoted they might have 3 or 4 bullet points to their name instead of 1.
Of course, over-simplification is the wrong decision some times, the same as abstraction and complexity is the wrong decision some times...
Your shortcut for promotion is generally building value for the company, but people need to remember that promotions support the business and they aren't free to the company.
Unfortunately, no, simpler systems often take longer to create. It's always easiest to just add some janky widget hanging off the side, than to rejigger the whole system to be simpler. It's like the Pascal quote: "I have made this longer than usual because I have not had time to make it shorter."
They take less to review and maintain etc, but the credit for those positives aren't assigned to the original engineer. Which is the point of the article.
Shipping a button in 2026… <https://www.youtube.com/watch?v=xE9W9Ghe4Jk>
This is playing out in real time with AI. Someone uses ChatGPT to compress weeks of work into hours, and the organizational response isn't "great, let's scale this" -- it's panic about what it means for headcount and hierarchy.
There's a short film making the rounds that captures this perfectly -- an employee uses AI to generate the quarterly results his whole department was working on, and instead of being promoted, he gets fired: https://youtu.be/O5FFkHUdKyE
The simplicity penalty is even worse when the simplification comes from AI. It's not just "you made us look bad" -- it's "you made our entire team look unnecessary."
What's going on here? There's a AI generated song in a youtube video, but it was posted yesterday and this bot is here today. Did someone have future sight of what today's HN post was going to be?
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 ).
Sounds like an inverse Peter Principle... the people who are best at their jobs will stay in that job while people who care enough about promotions to sabotage their work will get promoted out of a position to do damage.
FAANGs are notorious for promoting complexity, and the results are there for all to see.
One thing engineers can do to fight this, and I think it's mentioned in the article, is to write extensive documentation. Bosses in these companies are too lazy to dig into solutions and figure out for themselves; so they resort to proxies like the number of lines of code, number of pages in the design doc, etc.
Unfortunately, some of us who aim for simplicity are also averse to writing long docs; but with the advent of LLMs, there is some relief in sight.
My career has suffered a lot in terms of promos, etc. because I hate complexity.
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?
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupéry.
It's hard to keep things simple. Management should be mindful of that and encourage engineers to follow YAGNI, to do refactorings that remove more code than they add, etc.
You can sell simple solutions as complex by focusing on what they solve. No one has to know your solution is simple unless they're looking under the hood.
And complexity doesn't always sell better. A lot of times it might look like the whole thing is messy, or too hard to maintain, tech burden nightmare. Things that are simple might look complex and vice versa too, I think anyone who had to implement requirements from people who don't understand the implementation complexities will know this very well.
Related: https://news.ycombinator.com/item?id=47242765
That is dead, but I vouched for it.
The incentive misalignment gets worse when you factor in hiring pipelines. A team that keeps their stack simple has fewer "impressive" bullet points for resumes, which makes it harder to hire senior engineers who want to work with "interesting" technology. So there's pressure from both ends — management rewards complexity, and talent acquisition inadvertently selects for it. The orgs that consistently reward simplicity seem to be those where senior engineers have enough credibility to push back and say "we already solved this with three lines of SQL."
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.
Sad but true. I'm very strict with my developers and extremely cautious of introducing new "moving parts" to existing systems. I try to keep a single deployment-unit if possible. I like monoliths.
I just refactored a bunch of our microservices into a monolith. Fortunately the business justification was pretty straightforward because it was clear to all of us that the service architecture was weighing us down.
Since one of microservice's benefits is solving a coordination problem, now that teams are getting smaller due to AI, I wonder if we will see monoliths make a resurgence in some cases.
Haha. This title: Nobody Gets Promoted for Simplicity
This was the model at my last job. The "director" of software had strong opinions about the most random topics and talked about them like they would be revolutionary. His team was so far from the product teams they would just build random crap that was unhelpful but technically demo'ed well. Never put into practice. Promoted for 4 years, then fired.
Just about every project I've ever worked on eventually needed everything.
So the way we write software piecemeal today is fundamentally broken. Rather than starting with frameworks and adding individual packages, we should be starting with everything and let the compiler do tree shaking/dead code elimination.
Of course nobody does it that way, so we don't know what we're missing out on. But I can tell you that early in my programming journey, I started with stuff like HyperCard that gave you everything, and I was never more productive than that down the road. Also early C/C++ projects in the 80s and 90s often used a globals.h header that gave you everything so you rarely had to write glue code. Contrast that with today, where nearly everything is just glue code (a REST API is basically a collection of headers).
A good middle ground is to write all necessary scaffolding up front, waterfall style, which is just exactly what the article argues against doing. Because it's 10 times harder to add it to an existing codebase. And 100 times harder to add it once customers start asking for use cases that should have been found during discovery and planning. This is the 1-10-100 rule of the cost of bugs, applied to conceptual flaws in a program's design.
I do miss seeing articles with clarity like this on HN though, even if I slightly disagree with this one's conclusions after working in the field for quite some time.
This is so weird to read given the quote at the top. The kind of simplicity Dijkstra is talking about is a form of abstraction. He's talking about elegance. While the author is talking about a different type of abstraction, more like the image or a Jackson Pollock painting. Look at how Dijkstra talks here [0].
When a scientist says "simplicity" they mean "elegance". This is very different from "easy to understand". There's a reason that quote says simplicity is difficult to achieve. This doesn't seem in line with the author's examples. But it's easy to see what Dijkstra was talking about. Have you ever derived an equation in math or physics? You start one place, do a whole lot of work, and then you get out this "simple" thing. You could write pages of math to come up with an equation that uses only a few symbols. E=mc^2 is simple but getting there was very hard and took a lot of time, thinking, and abstraction.
The author conflates simplicity with speed, not with what the end result is and how well it solves the problem.
Why are CS people against abstraction? All we do is abstraction? We act like all abstraction is the same, and it's evil.
We have to be more nuanced. I could see the entire blog post written in the exact other way where engineer A gets promoted because they complete more tickets and engineer B doesn't because they take too long. But the reality is that from such a high level we can't determine which solution is right. Sometimes A's method is the best and sometimes B's is the best. But we don't know the impact. B's solution could create more problems, like the author suggests, but also it could solve many problems that don't end up appearing. Same for A's solution!
I don't like this over simplification and the author's conclusion is naïve. If we make everything understandable to everybody then it's a race to the bottom Who does it need to be understandable to? The senior? An experienced developer? A junior? A manager?
Don't get me wrong, there's tons of unnecessary complexity out there and that's bad too. But for that I'll reference Knuth's famous and misunderstood quote where he says "get a fucking profiler before optimizing things". He too is talking about elegance, but a balance of how we should prioritize things.
[0] Concern for Correctness as a Guiding Principle for Program Composition https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...
This resonates so hard with me. I was self-employed for over eight years, since I was the one who had to deal with all messes I always made sure that things were as simple as sensible (but not simpler). I made a good career out of it. Then I went back to being employed by a company, and I was completely befuddled but the over-complication of designs. Engineers aren't trying to help the business or solve a problem, they're trying to prove how good they are. It's just the completely wrong set of incentives. If you only get promoted by solving complex cases and there are no complex cases to solve, then you'll make them up.
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.
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.
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
I think it's simpler than that, you get noticed and then maybe promoted based on what you deliver. The ability of delivering what you were asked to, on time, or even before that.
Adding extra things can always help, specially like in the UI side of things, since higher ups will probably just notice that part.
I just dont agree with this and it hasnt been my experience.
Your job is to deliver value. If you can get stuff done quicker and without it breaking, you did great. Some one who spent more time doing the same thing except took longer and has a more brittle solution they have to keep going back and fixing doesn't look good.
And simple solutions are easier to explain and convince people.
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.
True.
By chance, recently in an architecture discussion document I added that one of aspects to consider is how easy is to remove (the whole thing) if it's not wanted anymore.
It was an obvious case because it was an AI capability, which can be become deprecated/useless/too-risky very fast.
Adjacent to it are PR reviews. Suggesting simpler approach in PR almost always causes friction: work is done and tested, why redo? It also doesn't make a good promotion material: keeping landscape clear of overengineered solutions is not something management recognises as a positive contribution.
Depends on the management and whether they're involved in coding. Any engineering manager, architect, senior / lead developer etc should appreciate lower complexity.
Of course, if it's the person in charge introducing said overengineering there is a problem.
they can recognise on the informal level, but you can't put it into end of the year review document. What it will be? "Kept N PRs from introducing cruft into our systems?". Fixing or building things is much more visible, than just maintaining high standards.
Worse, to suggest a simpler approach checking existing products/APIs or even preparing toy prototype is required to be confident in own advice. This hidden work is left entirely unnoticed even by well meaning managers/engineers: they simply don't know if you knew or had to discover simpler solution.
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).
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?
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.
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?
It's the definition of simple that's the problem. For any definition of simplicity you might have, someone has an equal and opposite definition.
Take these two alternatives:
There are some coworkers who will veto the first example for being too complex, because it brings Postgres (and its state and connections and exceptions and mappings) into the scope of what otherwise could have been a service concerning Users.There are some coworkers who will veto the second example for being too complex, because Postgres is all you use for now, and if you really need to use a second database, you can change the code then (YAGNI). Also the Interface gives you a pointless indirection that breaks IntelliSense so you can't just 'click-through' to follow the code flow.
I agree with your comment, but I disagree a both the example opinions... complex is the discussion :D
I heard something that helps better framing those discussions, use "familiar" instead of "simple".
An highly abstract way to access a database table, with ORM for example, can be simple because everyone is expecting it and knows how to do all tasks (changing schema, troubleshooting, managing transactions, etc.).
Doing userService.pgSql("select ....") in the same way can be simple.
I recently had a performance review at a FAANG. One engineer on my team has spent the past 3 years working on a complex infrastructure migration which involved about 20 engineers. The migration was completed last year and saved the company some opex costs.
I on the other hand spent 3 weeks optimizing our core service and reduced 2x the opex costs of the large complex 3 year migration.
In my yearly review my manager acknowledged my impact, but said I need to solve more complex problems to get to Staff Engineer. I protested saying that my 3 weeks of work had a larger impact than 20 engineers over 3 years, but he told me that is just how it works.
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.
Your plumber is probably making a good choice. Valves that don’t get exercised regularly can be all but guaranteed to be a pain in the ass when you need them to work.
We have a calendar reminder to exercise the valves in our house yearly, and the fact that they’re easy to get at helps make sure it’s a quick job, not a tedious one.
Not a plumber, but have lived in enough old houses with iffy valves to have been bitten a few times.
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.
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.
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.
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.
It's rare to have two engineers working separately but on exactly the same problem so their results can be directly compared.
Bigger picture, when the thing you try to measure is subtle and difficult, you measure something obvious. That's what happening here.
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.
This is true, but since the article mentions interviews. They're a game in itself.
The irony of simplicity is that people often talk about it, yet the concept is so complicated that they fail to define it.
I imagine Steve Jobs would not have agreed with the statement "Nobody gets promoted for simplicity".
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
Posted just yesterday: https://news.ycombinator.com/item?id=47242765
Totally tangent, a startup get promoted to getting funded if the business model is simple. May be opt for a startup.
The implication and manifestation of Dijkstra's observation are routine happening in IT ... God bless info tech.
You can though. You can build a simple system that's easy to operate, and just sail it in.
I’ve known some pretty simple managers that got promoted pretty quickly.
"The Parable of the Two Programmers" by Neil W. Rickert is pretty much about this, from the year 1985...
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.
One more opinion piece uselessly recommending "simplicity" with no code samples or concrete takeaways.
> It also shows up in design reviews. An engineer proposes a clean, simple approach and gets hit with “shouldn’t we future-proof this?” So they go back and add layers they don’t need yet, abstractions for problems that might never materialize, flexibility for requirements nobody has asked for. Not because the problem demanded it, but because the room expected it.
$100 says the "clean, simple" approach is the one which directly couples the frontend to the backend to the database. Dependencies follow the control flow exactly, so that if you want to test the frontend, you must have the backend running. If you want to test the backend, you must have the database running.
The "abstractions for problems that might never materialize" are your harnesses for running real business logic under unit-test conditions, that is, instantly and deterministically.
If you do the "simple" thing now, and push away pesky "future-proofing" like architecting for testing, then "I will test this" becomes "I will test this later" becomes "You can't test this" becomes "You shouldn't test this."
If they could read, this would upset managers at Amazon.
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
The problem simplicity is facing is mentioned in TFA with the keyword "future-proof", which is the typical instance of FUD in software. It is extremely difficult to fight against it, as, just like fake news, it would take 10 times more effort to debunk it than to make it. Yes, you spell out the cost of the additional layer, but it is invariably answered with "that's not so expensive", and risk aversion does the rest.
Sqlite, the one trick interviewers hate!
Complexity is the enemy of success - Tony Robbins.
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.
Article seems to suggest that simplicity vs complexity is a sort of a binary, or at least a spectrum. In fact, it's very often the case that:
* You can have a bunch of simple code for a latent or implicit concept that is complex; and that making the code more complex might make the reflect principle simpler.
* You have trade-offs: If one aspect is simple, other aspects must become more complex to accommodate.
* There is no consensus over what constitutes complex vs simple code.
Well you do get promoted for simplicity if you outperform others, who do things too complicated.
For example, person A implements the simple solution, gets the project done faster while person B over engineers, has seemingly impressive stuff to talk about but at the end of the day doesn't ship.
It's not just that it looks good, there is constant pressure from other Engineers that we should "Do it right" and "Plan for the future" even if the future is murky and every design choice we take for scalability is probably just constraints that will hinder us if the requirements change.
as a manager its constant fighting the pressure to build "Great software" that is way above what the company needs instead building working software that addresses customer needs in a timely manner.
My dude we are s startup with two servers and 20 customers, we do not need infinite scalability.
I promote people for simplicity
This is definitely a "known problem". At my company we call it "promotion-driven development". The promotion guidelines call out that knowing when _not_ to build something is important, but how do you put that in a body of work? "Decided not to build A". Nobody cares.
I feel this. I once worked for this manager, and whenever we finished a sprint, the first question he ALWAYS asked was "What tool(s) did you use/implement?" Many times, the answer was "No tools, I just banged out a bit of code to do the job.", only to get looked at for several seconds before he looked disappointed, and moved on. It was infuriating!
What in case engineer picks a simple solution that is hard to understand, cant be tested and next person that comes looks at it and says “wth is that?”
In case you ask “how can simple solutions be hard to understand and test?”
Lets just say you use single line bash scripts with multiple pipes, loops and very niche cmds.
It will work, it will look like nightmare, it will be simple -> one line.
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
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.
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.
I hate clickbait titles like this. Of course, some organizations appreciate and reward simplicity. Mine does.
It's great to choose simple solutions to avoid over-engineering, but at the same time you need to be able to talk about them in a way that proves making that choice was much more complex than picking the complex path directly. Listing both the complex solution and the simple one shows others that you reasoned about both and deliberately chose simplicity. It's all about framing the story behind the decision.
When I'm on a team and there are multiple engineers and data scientists, many of them come from Big Tech: Google, Microsoft, Apple, etc. I don't get any points with them for implementing a one-liner that does whatever Google implemented but they get very excited if I did. I get a "Oh wow, I know someone who worked on that at Google, I am really glad it's useful!"
This extends to suggesting huge licenses like from Salesforce. The Marketing and HR teams are ecstatic that they can purchase another license of their favorite software, they can go shopping! If I had implemented a free and more efficient CRM, there would be no networking effect.
This all builds systems that are vastly more expensive (to the tune of hundreds of thousands of dollars), slower, and much harder to fix. YCombinator financially benefits from this and it's all very corrupt. Most of the time, I have to really gain the "soft skills" to activate the networking (nepotism) effects.
It's not about what you know, it's about who you know.
Yep people get promoted for bullshit throwaway projects that are built in the fastest & dirtiest way possible so that management can dance & clap about how brilliant everyone is about every 2-4 weeks.
All this is game theory top to bottom. The only way to really quantify productivity is to look at "how much" of a thing has been created. In this case, lines of code, features, files, etc... So of course people who want to maximize their own income through promotions will also be incentivized to maximize the only quantifiable thing that they're judged on.
We all know this, but no one is willing to fix it.
Be the change you want to see in the world. If you are in management, promote those that see the value in simplicity.
Earlier discussion: https://news.ycombinator.com/item?id=47242765
Steve Jobs
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?
"less is more"
what a pub/sub hater
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.