Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody gets promoted for simplicity

terriblesoftware.org

Post reply on HN
Print view View original

171–180 of 534 posts

Re: Nobody gets promoted for simplicity

#171

Post by MrBuddyCasino »

PKop wrote: post #140
MrBuddyCasino wrote: post #132

Earlier quoted context omitted.

> They made him do it again and he passed. I would hire the "just use postgres" dude in a heartbeat without re-testing, if the numbers made sense, and perhaps give a stern talking-to to the interviewers. But then again I'm not a unicorn founder, so what do I know.

Eh, it's a good answer and shows good instincts, but they still want to know how he would design a system if one was necessary. There's no need to be ridiculous about any of this from either perspective, which is why it should never have been a "fail" without the original interviewer simply saying "That's a solid answer now tell me what you would do if you had to build something new". I mean look how much time he was…

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.

Re: Nobody gets promoted for simplicity

#172

Post by NoSalt »

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!

Re: Nobody gets promoted for simplicity

#173

Post by youknownothing »

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.

Re: Nobody gets promoted for simplicity

#174

Post by musesum »

mattcollins wrote: post #45
Niko901ch wrote: post #21

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, 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"

instructions.md is the new intern.

Re: Nobody gets promoted for simplicity

#177

Post by mauvehaus »

randusername wrote: post #36

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-confidenc…

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.

Re: Nobody gets promoted for simplicity

#178

Post by lucianbr »

MrBuddyCasino wrote: post #132
tyre wrote: post #91

Earlier 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…

> 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.

Re: Nobody gets promoted for simplicity

#179

Post by Steve16384 »

arealaccount wrote: post #168

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.
Post reply on HN