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

131–140 of 385 posts

Re: The Worst Programmer I Know (2023)

#131

Post by andix »

The title should be: Why measuring developer productivity by story points is bad.

I was once part of a team that had a zero-storypoints developer too, let's call him Zero. He always refused to get any stories assigned during planning, his goal was always zero. He felt responsible for delivering all the planned stories and helped the people who struggled. He often came to me and told me to help someone on a specific task, because it was too much for him to help everyone.

This was well understood by management though. Zero took a 4-6 week vacation every year, and management always pushed important releases back if Zero was not there. The team could've done it without him, and it might've been better for the team not to have Zero around for all important releases. But management was scared something could go terribly wrong without him.

Re: The Worst Programmer I Know (2023)

#132

Post by hansmayer »

whatshisface wrote: post #50
bberenberg wrote: post #45

Earlier quoted context omitted.

I don’t think anyone is saying it’s a good solution. It’s one amongst many bad ones that are used because that’s what we have. For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels. One of the reasons is to see who’s spending a lot of time lending a hand. Guess what, devs refuse to do that. So what am I supposed to do? I have a person who I…

It sounds like your employees believe that talking to you or amongst each other, where you can read it, will get their friends laid off or bad decisions made without advice. You might want to put a layer of management between you and them, if you can find someone with the skill of trust and relationship building.

I think a competent technical lead would do wonders in this case too ;)

Re: The Worst Programmer I Know (2023)

#133

Post by lolinder »

suzzer99 wrote: post #107
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…

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.

> 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 works for Junior through Senior level roles, but it falls apart quickly when you have Staff+ roles in your company. Engineers in those roles still code, but they write a fraction of what they used to and that is by design—you want these people engineering entire initiatives, integrations, and migrations. This kind of work is essential and should be done by your top devs, but it will lead to many fewer commits than you get out of people who are working on single features.

With a few exceptions for projects with a high degree of source-level complexity, a Staff+ engineer who's committing as much as your Senior engineers is probably either misleveled or misused.

Re: The Worst Programmer I Know (2023)

#135

Post by Izkata »

motorest wrote: post #22
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…

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

More like bug/case tracking is crap on this. All the ones I've ever used only support one assignee, so even in equal pair programming you have to choose who officially gets the case.

They're suggesting working around the case tracker, not around the metric.

Re: The Worst Programmer I Know (2023)

#136

Post by ryandrake »

ModernMech wrote: post #126
neilv wrote: post #67

Earlier quoted context omitted.

Not everyone will play the metrics games. Some people will just find the metrics dumb and depressing, and avoid them. (As might've happened in the article.) Some assume it will go away in time, or that their manager will cover for them. (As eventually happened in the article.) Some have behind-the-scenes talks with managers+execs+HR, to end bad metrics. Some will melt the metrics with the intensity of their look of d…

Yup, I didn't play the metrics game, and I got burned because my metrics don't look as good against the co-worker who plays the game. The cost is having to remind everyone how much work you actually get done and how much you actually support the team when those "your metrics tell us you're not doing enough" talks come up.

I've resigned myself to the reality that every employer is basically the same in this regard. You need to be spending 25-50% of your time doing your actual work and 50-75% of the time doing all that political and self-promotion and metrics-chasing work so that you can "show your impact" or whatever the hell your company calls it. This has been the case at literally every job I've ever had. If you just go in as an expert and do the technical work you were hired to do 100%, you're going to have a bad time career-wise.

Re: The Worst Programmer I Know (2023)

#137

Post by fsndz »

smokel wrote: post #123
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

Perhaps give it some time before judging too harshly?

vibe coding has been in the scene since the emergence of ChatGPT perhaps...

Re: The Worst Programmer I Know (2023)

#139

Post by dahart »

franktankbank wrote: post #117
dahart wrote: post #62

Earlier quoted context omitted.

Do you have experience being a tech lead and/or a manager? Tech leads and people managers are two explicitly different roles in many organizations, for good reasons, including, but not limited to them being both full time jobs. It certainly depends on the company and the size of the team and other things, but many many tech leads are not at all comfortable hiring & firing, nor with interviewing and prioritizing work…

Man that is a whole lot of fluff to differentiate between being able to hire and fire. I wonder what Tim would do.

So your mind is made up that someone fictional who is not described in a blog post does not contribute to an org you know nothing about? Is your point that all management is useless? Or something else? And why are you certain, what is your experience running a team or a company? Maybe the sarcasm isn’t communicating your point effectively?

Re: The Worst Programmer I Know (2023)

#140

Post by eclipxe »

fsndz wrote: post #127
sanex wrote: 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.

it's definitely nice for prototypes, but nothing more complex.

I used to feel that way but my perspective over the last 6 months has changed greatly. You can absolutely build very complex things in this style
Post reply on HN