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.
Nobody gets promoted for simplicity
161–170 of 534 posts
Re: Nobody gets promoted for simplicity
#162I 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…
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.
Re: Nobody gets promoted for simplicity
#163I 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 "…
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.
Re: Nobody gets promoted for simplicity
#164Earlier quoted context omitted.
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 e…
> okay, well yes you might be right but you also understand what the point of the interview is. So the point is? I honestly dont understand.
In an interview you need to explain your thought process and demonstrate that you’re making an informed decision with supporting evidence.
Saying “just use Postgres” and then providing no explanation for why you believe Postgres is sufficient for the job, a general explanation of what type of hardware and architecture you’d use, and other details is not answering the question.
Re: Nobody gets promoted for simplicity
#165I had an interview question. What would you do if two different people were emailing a spreadsheet back and forth to track something? I said I’d move them to google sheets. There was about five minutes of awkwardness after that as I was interviewing for software developer. I was supposed to talk about what kind of tool I’d build. I found it kind of eye opening but I’m still not sure what the right lesson to learn was…
So my cofounder was talking to Stripe about an acquihire (this was after I’d left.) As part of it, he had to do a systems design interview. He got the prompt, asked questions about throughput requirements (etc.), and said, “okay, I’d put it all in Postgres.” He was correct! Postgres could more than handle the load. He gets a call from Patrick Collison saying that he failed the interview and asking what happened. He e…
> 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?
Re: Nobody gets promoted for simplicity
#166I had an interview question. What would you do if two different people were emailing a spreadsheet back and forth to track something? I said I’d move them to google sheets. There was about five minutes of awkwardness after that as I was interviewing for software developer. I was supposed to talk about what kind of tool I’d build. I found it kind of eye opening but I’m still not sure what the right lesson to learn was…
So my cofounder was talking to Stripe about an acquihire (this was after I’d left.) As part of it, he had to do a systems design interview. He got the prompt, asked questions about throughput requirements (etc.), and said, “okay, I’d put it all in Postgres.” He was correct! Postgres could more than handle the load. He gets a call from Patrick Collison saying that he failed the interview and asking what happened. He e…
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.
Re: Nobody gets promoted for simplicity
#167This 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 departme…
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.
Re: Nobody gets promoted for simplicity
#168I'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.
Re: Nobody gets promoted for simplicity
#169AI 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, onb…
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.
Re: Nobody gets promoted for simplicity
#170Earlier quoted context omitted.
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 e…
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
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.