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

261–270 of 534 posts

Re: Nobody gets promoted for simplicity

#261

Post by erelong »

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"

Re: Nobody gets promoted for simplicity

#262

Post by Cthulhu_ »

musesum wrote: post #169
mattcollins wrote: post #45

Earlier quoted context omitted.

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; i…

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

Re: Nobody gets promoted for simplicity

#263

Post by ajspig1 »

bilsbie wrote: post #73

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…

  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.

Re: Nobody gets promoted for simplicity

#264

Post by erelong »

codingdave wrote: post #2

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.

"Code footprint is 80% more efficient / less"

(when there is a simpler design over more complex "big ball of mud abomination" in contrast)

Re: Nobody gets promoted for simplicity

#265

Post by Aurornis »

wadadadad wrote: post #185
Aurornis wrote: post #170

Earlier quoted context omitted.

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

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

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.

Re: Nobody gets promoted for simplicity

#266

Post by pm90 »

erelong wrote: post #261

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

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.

Re: Nobody gets promoted for simplicity

#267

Post by munchbunny »

badosu wrote: post #123
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…

Sorry, I didn't get it. What was the 'right' answer?

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.

Re: Nobody gets promoted for simplicity

#268

Post by tracker1 »

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.

Re: Nobody gets promoted for simplicity

#270

Post by 01284a7e »

munchbunny wrote: post #248
bilsbie wrote: post #73

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

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.

Post reply on HN