Live data from Hacker News

Nobody gets promoted for simplicity

terriblesoftware.org

501–510 of 534 posts

Re: Nobody gets promoted for simplicity

#501

Earlier quoted context omitted.

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

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.

Not the GP, but when I take strolls through some open source project hosted on GitHub, usually I am not impressed either. Unnecessary OOPism, way too long procedures, that instead could be pure functions, badly named variables, and way, way, waaay too many willy-nilly added dependencies. If that is what the LLMs mostly learn from, I am not surprised at all. But then again this stuff was also written by humans. I remember one especially bad case of a procedure in a very popular project (in its niche) that was basically a 1 man show. A procedure of 300+ lines doing all kinds of stuff, changing the global state of that service it is implementing. But that code was or is relied upon by tech giants and other businesses and no one improves it. They are happy with paying that one guy probably not so much money.

Re: Nobody gets promoted for simplicity

#502

Earlier quoted context omitted.

Neither do most humans writing such code, i have seen llms generate better code than 90% of coders I have seen in the last 20 years

This says more about you and the people you work with. I find engineers that have been at the company for a while are quite invaluable when it comes to this information, it's not just knowing the how but the when + why that's critical as well. Acting like people can't be good at their job is frankly dehumanizing and says a lot about your mindset with how you view other fellow devs.

If only more engineers admitted, that something they wrote is not good code, but a product of its time, then I think we would get more realistic expectations.

It's OK to say that something you made is shit. It is OK to say that you were not given time to do xyz.

How you recognize something has been made fitting at least is, when you see it in use without much of a change for some 3 or 4 years and while you are the person maintaining it, you rarely ever need to touch it, because you built it in a way that is simple enough to not have tons of bugs yet flexible enough, to cover use-cases and anticipated use-cases.

Re: Nobody gets promoted for simplicity

#503

Earlier quoted context omitted.

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

Sadly, many interviewers will be fine with someone who simply memorized without actually understanding much, and not fine with someone needing to think and slowly coming to a solution, being able to explain it, because oh that did take more time than the interviewer had allotted for the task. Sadly, many interviewers and the adjacent HR departments are utterly failing in the communications part too.

Re: Nobody gets promoted for simplicity

#505

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.

> "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 b…

[deleted]

Re: Nobody gets promoted for simplicity

#506

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.

> "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 b…

[dead]

Re: Nobody gets promoted for simplicity

#507

Earlier quoted context omitted.

There is a difference between being smart and acting smart.

I think that's exactly the point being made. __Acting__ smart gets you paid, not being smart, and that's like, not ideal.

I wonder how you get paid if you fail the interview.

Re: Nobody gets promoted for simplicity

#508

Earlier quoted context omitted.

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

That's a good part of why I want to stay in the IC track. I don't care about having the power to hire/fire people. That's a manager/lead skill in my eyes. Maybe we have a small conversation with candidates, but I see no reason I need to be quizing people on their talents.

It's almost as if we're saying your resume means NOTHING. I have thought about how to solve this, and my brain comes up with some LinkedIn alternative specifically driven by developers vouching for other developers.

Re: Nobody gets promoted for simplicity

#509

Earlier quoted context omitted.

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.

In an interview setting this is such obvious bait to see if the person will ask more questions or go straight into making a solution.

Re: Nobody gets promoted for simplicity

#510

Earlier quoted context omitted.

> when the moment calls for it In an interview when you’ve been explicitly asked to discuss a topic to have a technical discussion about something is not when the moment calls for it. Doubly so if you’ve been asked twice. If you’re not willing to put aside being technically correct when you’re trying to show off your best self, it’s pretty likely that when things get tough, you’ll behave the same. > unless of course…

>do you think that someone saying “can we please talk about a technical topic, here’s an example we’re both likely familiar with” is looking for yes men? Probably. You say "likely familiar with" but interviews are conducted as if it's a pop quiz. Which I never understood. If you want to have a decently technical discussion, why not just tell me ahead of time what topic and I come to the interview with research? Why d…

> You say "likely familiar with" but interviews are conducted as if it's a pop quiz. Which I never understood.

Sure - the point of being familiar with it is so that we don't have to spend a chunk of the very limited time we have explaining a problem space, and we can talk about the technical stuff.

> If you want to have a decently technical discussion, why not just tell me ahead of time what topic and I come to the interview with research?

I try really hard to design interviews to not require take home work. I don't have stats to say whether this is right or not, but my goal as a HM is to try and keep the process to recruiter/HM call, 1/2 tech interviews and an interview with someone else on the team who is not a programmer (I hire in games so you're pretty much guaranteed to be working with Artists/Designers).

Post reply on HN