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

241–250 of 385 posts

Re: The Worst Programmer I Know (2023)

#241

Post by dragonwriter »

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…

“Your onboarding will be making collection calls.”

So, your AI debt collection startup onboards engineers by...having them work as human call-center debt collectors?

Is there really AI at all?

Oh, but after passing through the onboarding, your vibe-coding engineers will be be focussed on building product by vibe coding, right?

“(what you will be doing...) Onboard customers, talk to them and travel to visit them.”

So, a traveling sales rep. Your onboarding is pretending to be the product, and after that you are a traveling sales rep who vibe codes on the side?

Re: The Worst Programmer I Know (2023)

#242

Post by mx_03 »

OnionBlender wrote: post #108
morsecodist wrote: post #94

The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables. Measuring story points or lines of code is kind of the opposite of productivity. This encourages developers to do as much meaningless work as possible. I'd want a developer to make a task simpler or use an existing tool which means less time writing code. The valu…

I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code. One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem…

> The problem was that this intern was bad, so we had him write unit tests.

Please tell me you assigned this person a "increase code coverage" task and not "I wrote a new feature, write the unit tests for it" task

Re: The Worst Programmer I Know (2023)

#243

Post by move-on-by »

crazygringo wrote: post #205

I agree with a couple other comments here -- this is a bizarre model where one programmer does no individual work and does all the helping. A much healthier situation, to me, is one where Tim does stories like everybody else, and when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while. Surely there are easier stories for those who need the most…

> when people need help they ask the group and whoever is the best at that thing helps them -- or whoever hasn't helped in a while.

I agree this would be healthy for an organization, but I don’t think that is often possible. In this example, the organization is clearly NOT tracking mentor activity. So, anyone who helps someone else, is getting zero recognition for it.

I work with a lot of people where ‘ruthless prioritization’ is considered a good quality. That means no one gets any help. All taking. No giving. Pure selfishness really.

Back to the example. Tim is stepping up and filling in a major gap for the company. People need help. He has decided to go against the grain and help. However, instead of doing it with the help of leadership, he is just doing what needs to be done and it almost cost him his job.

Frankly, I identify with Tim. I love helping people figure out problems. Be it build env issues, failing tests, or some design gap. I help people all the time on top of my other work. While my immediate manager knows that and is good with it, upper leadership doesn’t care and just wants everyone to act like what they are working on is more important then what their peers are working on. Ruthless prioritizing is a seed of toxicity.

I got a bit off topic… How to encourage helping peers and juniors when helping isn’t tracked and isn’t rewarded or encouraged? How do you maintain a healthy culture despite all the metrics?

Re: The Worst Programmer I Know (2023)

#244

Post by closeparen »

winwang wrote: post #142
suzzer99 wrote: post #107

Earlier quoted context omitted.

Dev productivity is like quantum mechanics. The second you try to measure it, the wave function collapses, and you've fundamentally altered the thing you were trying to measure. 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. This Tim sensei situation may be more common than I think, but I've never run into it.

With my minor dabbling in game theory, I've considered funny angles like secret-ish internal metrics and punish those who simply game the incentives. Example: bot detections and banwaves in MMOs. Instead of instantly banning plausible bots, the company has to hide its (ever-changing) internal algo and ban in waves instead. Basically, treating (non-)productivity like bot detection, lol.

A few years ago we started tracking both office attendance and PR count. Management swore up and down that they understood the nuances, and these metrics would only be used to follow up on outliers.

But then one middle manager sets a target. His peers, not to be outdone, set more ambitious targets. And their underlings follow up aggressively with whomever is below target. For a few months there was an implicit "no vacations" policy in much of the company, until they updated the attendance dashboard to account for PTO. And now an engineer's position in the stack rank is presumed to be her position in the PR count rank barring very strong evidence to the contrary.

The approach you outline is probably optimal, but I don't think middle management as a culture would be capable of pulling it off. You give them a KPI in a dashboard, they're going to compete on it, in a very open and simple way. Metrics are hard to argue with, and nuance requires constant vigilance to maintain.

Re: The Worst Programmer I Know (2023)

#245

Post by j-bos »

Aeolun wrote: post #238
paradox460 wrote: post #181

Earlier quoted context omitted.

Reminds me of a manager and a QA I once knew. QA was a nice guy, but a terrible QA. Would fail stories on the most arbitrary guidelines. Story is about changing the font size on the home page? He'd fail it because he wasn't able to log in (he tested while the auth service was undergoing planned maintenance). Manager loved this guy, and pushed him through several promotions. Eventually other employees got tired of bei…

We kinda have this, but… At least we have a dedicated QA team. That spends their whole day literally just confirming that the shit we write is up to spec. We spend a lot of time resolving discrepancies between implementation, spec and test, but when things roll out the other end, they work .

yeah a good qa team is peace of mind.

Re: The Worst Programmer I Know (2023)

#247

Post by thr0waway001 »

JohnMakin wrote: post #9

Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team again…

Ah, the "Quentin Tarantino presents" pattern. Nice.

Re: The Worst Programmer I Know (2023)

#248

Post by rpmisms »

slowtrek wrote: post #229
ponector wrote: post #217

Earlier quoted context omitted.

Are you going to accept such free rider in your team? You will eventually do both your and his tasks but for the same or worse pay. Given you have a fixed budget for the team - do you want to split it more ways? Where can I send a CV?

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.

Re: The Worst Programmer I Know (2023)

#249

Post by JohnMakin »

throwaway7783 wrote: post #40
motorest wrote: post #22

Earlier quoted context omitted.

> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by…

While a number measuring productivity may not work, I read the GP as simply recording contributions. I like that approach. Now you can not only have peer recommendations, but also tangible records.

In large org, i saw people quietly move up the ladder this way by being visibly effective even if their outright contributions may have been difficult for nontechnical or understaffed management teams can see. it’s an essential survival skill, not making any case whether or not it’s right to begin with - I often navigate these systems because I have to.

you will of course have people gaming the system but peers tend to realize what is happening there, and that’s a management problem IMHO

Re: The Worst Programmer I Know (2023)

#250

Post by linsomniac »

hi_hi wrote: post #221
OnionBlender wrote: post #108

Earlier quoted context omitted.

I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code. One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem…

Reminds me of an old joke about a policeman who pulls over a poor driver. The driver complain "But I haven't been in a single accident", the reply from the policeman, "Yes, but you've caused dozens". Some people are just oblivious to the trail of destruction left in their wake.

“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” ― John Ousterhout, A Philosophy of Software Design
Post reply on HN