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.
Nobody gets promoted for simplicity
501–510 of 534 posts
Re: Nobody gets promoted for simplicity
#502Earlier 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.
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
#503Earlier 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…
Re: Nobody gets promoted for simplicity
#504"Premature flexibilization is the root of all evil that is left":
https://product.hubspot.com/blog/bid/7271/premature-flexibil...
Re: Nobody gets promoted for simplicity
#505Sure 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…
Re: Nobody gets promoted for simplicity
#506Sure 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…
Re: Nobody gets promoted for simplicity
#507Re: Nobody gets promoted for simplicity
#508Earlier 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.
Re: Nobody gets promoted for simplicity
#509Earlier 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.
Re: Nobody gets promoted for simplicity
#510Earlier 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…
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).