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

The Worst Programmer I Know (2023)

dannorth.net

Post reply on HN
Print view View original

291–300 of 385 posts

Re: The Worst Programmer I Know (2023)

#291

Post by ykonstant »

bitwize wrote: post #175
fsndz wrote: post #114

Earlier quoted context omitted.

the worst programmer nowadays is the vibe coder. vibe coding is so overrated imo https://www.lycee.ai/blog/why-vibe-coding-is-overrated

Vibe coding is now a skill requirement for real, actual jobs but, thankfully I guess, no place I want to work (yet). The other day I saw a YC24 company in the "financial services industry" with a "vibe coder position". A prerequisite for the position was at least 50% of your current code being generated by AI; vibe-coding experience was "non-negotiable". Traditional programmers need not apply. And you'd better be rea…

Fortunately, vibe coding skills are easy to demonstrate through vibe statements of such; recruiters should be skilled in judging the vibe of the statement claiming vibe coding skills and accepting or rejecting it accordingly.

If, however, you are having trouble doing that as a recruiter, I am offering professional vibe-rating services as well as a full-blown software solution, the first of its kind, Job Market Vibe-Rater™.

Re: The Worst Programmer I Know (2023)

#292

Post by LandR »

lodovic wrote: post #282
psychoslave wrote: post #169

Earlier quoted context omitted.

Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.

Until a coworker needs to debug a specific edge case that was too specific for the single expression, and it all has to be rewritten back to long form. Dense code is not always better and sometimes makes a code base incomprehensable.

I've experienced this watching a coworker debugging that sort of code, he had initially written it all as a long chained statements, then had to undo it all to allow him to debug. Once it was extracted it could be debugged and step through it, great!

Once he was done debugging it he put it all back to how it was originally...

The mind boggles.

Re: The Worst Programmer I Know (2023)

#293

Post by eckesicle »

Kamq wrote: post #263
eckesicle wrote: post #189

Earlier quoted context omitted.

My wider point is not that the way companies are run is perfect and that we should stop the “innovators” (to quote the sibling comment). Each of these examples speak of corporate dysfunction, but we never give any weight to the constraints that force them in place. Leetcode is bad, but it’s bad in the sense that it errs too heavily on filtering out false negatives - the cheaper of the two errors. The alternative is w…

> Leetcode is bad, but it’s bad in the sense that it errs too heavily on filtering out false negatives But, it doesn't. It filters for something orthogonal to development, which is ability to obsess over clever algorithmic solutions. Ok, well my company does HackerRank instead of LeetCode, maybe LeetCode is magically better, but I'm not seeing anything that tells me someone who grinds LeetCode is actually going to be…

It only appears that HackerRank/Leetcode isn’t good at filtering because you’re viewing it from your perspective, and not the perspective of the entire population that is tested. To you, the predictive power at the top tail end of the distribution is low, because you’re thinking of two strong developers Alice and Bob. Alice happens to know algorithm X and would pass the test, whereas Bob does not. But that’s not the population we’re testing. Think more along the lines of Alice and Bob and your grandmother were the test population. It’s absolutely fantastic at filtering the lower 95% of applicants because they will _never_ be able to pass. Yes, inadvertently 2.5% of “good developers” are filtered too, but that doesn’t matter to the outcome of your company. They just want someone competent, and they don’t care if it’s Alice or Bob.

The same logic sort of applies to Tim and his performance. The bias of having an imperfect metric is probably much better than the bias of letting an army of middle managers go with their cut. Besides, it doesn’t have to be a hard filtering function at this stage, but a metric to indicate that we need to look a little closer at Tim

Re: The Worst Programmer I Know (2023)

#294

Post by milesrout »

hamburglar wrote: post #198
__turbobrew__ wrote: post #182

Earlier quoted context omitted.

> That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits Yea, in the current place I work at we do not measure coding performance metrics, but if you look at the top commiters to the repo — by number of commits — you will see all of the people who bring the most value to the company. Even at staff eng the best engineers are still the ones…

At my last gig I spent the last year and a half as staff engineer and made almost no commits because I was constantly writing proposals, defending them to execs, doing architecture reviews, doing design consultations, and planning long term responses to large incidents. I know for a fact that I brought a ton of value to the company but it was very uncoupled to commits. I didn’t really like it because I need to code,…

Writing proposals, doing architecture reviews and doing design consultations sounds to me largely like busywork and bureaucracy rather than real and productive work.

Maybe in a business where the cost of iteration is very high, it makes sense to do this. But in a good business you should not be doing architecture reviews and writing proposals, you should be doing refactoring and creating prototypes, respectively.

Re: The Worst Programmer I Know (2023)

#295

Post by saagarjha »

WalterBright wrote: post #274
dilyevsky wrote: post #265

Earlier quoted context omitted.

Frankly, I think you might be confusing "productive" with "smart" or "easy to work with". I've had several past team mates at several companies gush to me about staff eng Bob and while I agreed Bob was a cool guy (or just talked good game) I also knew his last few projects were a failure, it was 100% his fault, and management took notice. It happened in the other direction too but not as often. Alternatively you migh…

> I think you might be confusing "productive" with "smart" or "easy to work with". Working in teams for most of my career, and especially when I make or lose money depending on how the team performs, I am not confusing them. At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and comp…

> At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and complain about "Bob" who has annoying habits and an abrasive personality. I defend the ones that produce results.

And what if "Bob" makes it so that "Alice" who is almost as smart as him can't work effectively?

Re: The Worst Programmer I Know (2023)

#296

Post by milesrout »

rpmisms wrote: post #248
slowtrek wrote: post #229

Earlier quoted context omitted.

If we were to do this, we wouldn't just pick someone so out of the range of what's needed. So basically, if you reframe your question, would I hire a 70 average student on a team of 90 average students? Yes. We would not pick the 50 average students. This is all possible within reason, the kind of stuff being discussed in this thread is to purge people who are 80 average students (free riders in a 95 average class).…

My dangerous opinion is that the purpose of a company is to provide a living for its employees.

That isn't dangerous, just ignorant.

Re: The Worst Programmer I Know (2023)

#297

Post by milesrout »

saagarjha wrote: post #295
WalterBright wrote: post #274

Earlier quoted context omitted.

> I think you might be confusing "productive" with "smart" or "easy to work with". Working in teams for most of my career, and especially when I make or lose money depending on how the team performs, I am not confusing them. At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and comp…

> At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and complain about "Bob" who has annoying habits and an abrasive personality. I defend the ones that produce results. And what if "Bob" makes it so that "Alice" who is almost as smart as him can't work effectively?

You mean what if Alice is intolerant? Bob would have to be pretty egregious to make it so Alice cannot work effectively, and that is when HR gets involved. But if Bob is just not the easiest to work with, then it is up to Alice and Bob to work together. You can't expect everyone else to always adjust to what you want.

Re: The Worst Programmer I Know (2023)

#298

Post by saagarjha »

milesrout wrote: post #297
saagarjha wrote: post #295

Earlier quoted context omitted.

> At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and complain about "Bob" who has annoying habits and an abrasive personality. I defend the ones that produce results. And what if "Bob" makes it so that "Alice" who is almost as smart as him can't work effectively?

You mean what if Alice is intolerant? Bob would have to be pretty egregious to make it so Alice cannot work effectively, and that is when HR gets involved. But if Bob is just not the easiest to work with, then it is up to Alice and Bob to work together. You can't expect everyone else to always adjust to what you want.

No, I don't mean that. You assume that this is a logical conclusion but the problem is that "Bob would have to be pretty egregious to make it so Alice cannot work effectively" is not actually true. Bob, being the slightly better coder, could make Alice's life miserable without, like, doing a harassment that HR would be interested in. Constantly changing APIs that Alice relies on ("they're better now, why are you complaining?"), being overly nitpicky in reviews ("I'm not wrong, aren't I?"), or just outright taking the more interesting work ("I think I would do it faster than Alice") are all ways Bob could reduce Alice's productivity. If Alice is 0.9 of Bob, then instead of getting 1.9 Bobs you might get 1.2, while Alice plus Carl–who is just merely half a Bob–might be able to outperform that.

Re: The Worst Programmer I Know (2023)

#299

Post by LandR »

stickfigure wrote: post #271
bitwize wrote: post #175

Earlier quoted context omitted.

Vibe coding is now a skill requirement for real, actual jobs but, thankfully I guess, no place I want to work (yet). The other day I saw a YC24 company in the "financial services industry" with a "vibe coder position". A prerequisite for the position was at least 50% of your current code being generated by AI; vibe-coding experience was "non-negotiable". Traditional programmers need not apply. And you'd better be rea…

This must be satire. It is a stretch even for Poe's Law. Someone is punking YC.

Nothing about this job description sounds appealing, it has to be a joke.

Re: The Worst Programmer I Know (2023)

#300

Post by bsindcatr »

khazhoux wrote: post #280
bsindcatr wrote: post #15

Some things that don’t measure whether a developer is “good”: - # LoC added, changed, removed - number of points earned in a sprint, when those points aren’t quantitatively indicative of business value, and they never are - number of on or off-the-clock hours schmoozing with others to solidify relationships with the business and “play the game” - number of times they “sound like good developers / intelligent people”…

> Some things that don’t measure whether a developer is “good”: > # LoC added, changed, removed Everyone loves to say this, and yet at every company I've worked at, the top developers just cranked out code . High quality, performant code. And at every company I've worked at, the lowest performers would take a week to write 100 lines of basic python. "Oh, but khazhoux, those 100 lines were really very complex!" No, no…

You can make massive LoC changes by reformatting everything or just adding superfluous code or changes.

You can rip out a lot of code rewriting it to simplify and then losing a ton of business functionality that was used, or causing the need for a lot of business changes in process that might not be for the business’s benefit.

You can, on your own or with AI, write many LoC, and maybe it provides business value, which seems to align with being a “good developer”, but someone has to maintain those LoC, so then you have to weigh the business value to the end user and the team. Is it ok to the team to have all the extra LoC to maintain? How often will those changes eventually result in valid further changes to get that code to work? Will other devs just rewrite it and are their changes good?

So in the end, no, LoC added/changed/removed is not a good indicator of added overall business value when weighing both the business value to the user and the ongoing maintenance time that ensues, even though “good developers” along with “average developers” and even “bad developers” may have high LoC added/changed/removed counts.

During what some come to think as their peak years, they still don’t think of things this way. But as we get older and more experienced, we realize that sometimes new or old crappy code is ok, sometimes we should do a better job if it makes sense for the business and team, that many can contribute in their own way if those are the people and resources we have, things may change, and overall there is a limited amount that humans can do.

If you base performance on LoC and alter the team accordingly, you may lose great developers. You may also introduce volatility and risk later having a codebase that is higher cost to the business.

But embracing change and working fast and loose may also be important, so it depends.

Post reply on HN