Live data from Hacker News

The Worst Programmer I Know (2023)

dannorth.net

251–260 of 385 posts

Re: The Worst Programmer I Know (2023)

#251

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…

Everyone on a programming team knows who the good and not-so-good programmers are.

Kind of meaningless statement though. Even if they do, which Im not sure is true in general case because you have to be good yourself to know who’s really good, they are not telling you anyway.

Re: The Worst Programmer I Know (2023)

#252
post #165
post #118

Earlier quoted context omitted.

I think just because this startup botched OKRs they still make a lot of sense. Intel and Google apparently relied on them heavily in their formative years. But: - they should be cascading (so conflicting OKRs between departments should not happen) - you should never, ever tie them to individual performance results/compensation/rewards

My sense was OKRs came later for both Intel and Google. Do you know around what year/size they started? I worked with some ex-Google person who tried to get us to use OKRs. That totally didn't work. Larger company. Like many things I don't think they're necessarily a bad idea it's just that good ideas always lose to culture. With the right culture/leadership it's not the process that matters. I.e. OKRs aren't going t…

Google started using okrs at under 50 people because one of the board members was intel veteran. Not sure about the early years since i wasn’t there for that regrettably but in 2011 when i joined my impression of okr process was that it’s complete and utter bs and giant waste of everyone’s time. iirc google+ hit their okrs swimmingly…

Re: The Worst Programmer I Know (2023)

#253

Earlier quoted context omitted.

I would agree, but the manager probably should be in touch enough that they could see the teaming behaviour themselves.

They did… that’s the whole premise of the article

Not sure the story is even real but apparently that was going on long enough without his manager knowledge that the manager was dead set on making tims exit preparations

Re: The Worst Programmer I Know (2023)

#254

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.

As in, if you are on the ship, we can absolutely find something for you to do. Here, color the fucking map, clean the sails. Why would we throw them off the ship?

Re: The Worst Programmer I Know (2023)

#255

Earlier quoted context omitted.

Could a company keep a subjective poor performer on for the lifespan of the company? As in, what is the plus or minus in overall revenue or profit from this charity? What if all companies did that? Could we distribute the "burden" of the charity across all companies for a better society? My point is, I don't even know if metrics are good or bad, we may need to look at why we see each other like this. Is it so offensi…

This is what Japan does. Employment is presumed to be for life. There are games companies play to get out very poor performers but most people get approximately lifetime employment.

How was that society taught this? Or how did they come to know this?

Re: The Worst Programmer I Know (2023)

#256

Earlier quoted context omitted.

Everyone on a programming team knows who the good and not-so-good programmers are.

Kind of meaningless statement though. Even if they do, which Im not sure is true in general case because you have to be good yourself to know who’s really good, they are not telling you anyway.

In every organization I've worked in, everyone knew who the productive and non-productive people were.

Just like in school. Everyone knew who the good teachers were, and who the good students were.

I don't fathom how you can work with other people and not be aware of it.

Re: The Worst Programmer I Know (2023)

#258

These sort of stories seem to be dime a dozen and weirdly celebrated around HN and the software engineering community. We’re told of the hero, who goes against their managers and executives and doesn’t deliver any stories as agreed in sprints. We’re told of the engineer who isn’t hired by Google because he can’t invert a binary tree. Everyone else piles on and decree that, yes indeed, you cannot measure developer eff…

Agree in 1st and 2nd “meanwhile”. On the metrics thing though I have the opposite experience - mild distraction at best, total disaster and productivity killer at worst. Most orgs couldn’t even implement metrics fully (or at all) because in reality it is always much more work than they usually anticipate. Instead they larp as google and waste your god damn time.

Having said that i do think that there are a bunch of senior folks who think they are Tim but meanwhile they’re just hiding their laziness/incompetence by getting involved in other people’s shit

Re: The Worst Programmer I Know (2023)

#259
These articles are so predictable and always have a smug aura around them.

"Reports showed me the absolute worst programmer on my team. Did I fire him? No. I actually gave him a 20% raise.

Do you know why? He was the best programmer on my team (in disguise)."

Re: The Worst Programmer I Know (2023)

#260
post #116

Earlier quoted context omitted.

I've been writing code professionally for a decade but I've never written so much code in my free time because I can just vibe code it all. I wouldn't do it at work and I probably wouldn't trust a juniors vibes as much as my own but no tools have made me feel quite so powerful.

I never tried vibe code as described in this article, but I could see where it breaks. Initially, code works. Eventually, there's a bug, and the LLM isn't able to fix it. At that stage, you're on your own with a potentially large codebase which is totally new to you. Even on small projects, sometimes I'm tired, I just try to get the LLM do some refactoring for me or write a couple of tests. First, whatever the LLM wr…

The idea is "Rewriting is faster than debugging", so if something breaks, you ask LLM to rewrite it

Not a fan of it.

Post reply on HN