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

161–170 of 385 posts

Re: The Worst Programmer I Know (2023)

#161

Post by snapetom »

andix wrote: post #131

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

Wouldn't Zero be a hero in disguise, then?

When I hear stories about Tim or Zero, it makes sense... with the caveat of whether they are actually transferring knowledge to teammates, and whether the other team members are capable of taking over the function of Tim/Zero. If not, then Zero is just covering for low performers, and your bus factor is still a liability.

Re: The Worst Programmer I Know (2023)

#162

Post by lisper »

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…

> who was writing the most code

There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.

Re: The Worst Programmer I Know (2023)

#163

Post by MichaelRo »

eckesicle wrote: post #14

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…

>> To me, all these heroes, and above process people, just strike me as difficult to work with narcissists who are poor at communication. We are not special, and we do not sit above every other department in our organisation.

Exactly.

Looks to me like Tim was really good at hiding his incompetence behind other people's backs. Also looks like a problem of the others, particularly senior others of not telling him "Fuck off, Timmy" when he sat uninvited beside them to "pair program" together.

Re: The Worst Programmer I Know (2023)

#164

Post by nijave »

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.

I like looking at lines removed and, in context with, lines added or PR count. Someone more experienced will be refactoring and removing old stuff while adding new stuff and will have some balance (barring vendoring or moving file trees between repos)

Re: The Worst Programmer I Know (2023)

#165

Post by YZF »

bipson wrote: post #118
NalNezumi wrote: post #20

Glad to hear that Tim stayed and author managed to steer the entire process towards the right direction. Which requires a listening manager. I experienced the "bad ending" of this productivity metric trickle down: OKR. This startup wanted not just team-based 3-month review Objective Key Result but also individual one, and on top of it, tied stock option to OKR. It was a robotics startup so very cross-domain teams (So…

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 to fix an organization that isn't aligned and conversely there are infinite other ways to align an organization with the right culture and leadership. So in practice, like other things, it just ends up making things worse because it's never a real fix.

Re: The Worst Programmer I Know (2023)

#166

Post by morsecodist »

matusp wrote: post #158
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…

It is not absurd. From manager's point of view, when they are deciding to let someone go or promote them, they often need some arguments. And since software is invisible, it is often hard to just say straight away who is over/underperforming and why you think so apart from a "vibe" you are having. Measuring some relevant metrics can strengthen your argument and/or your overview of the situation. I don't think that th…

I don't think it is absurd to reason about individual contributions, just to focus on measuring them with metrics. I have been on the management side as well though I admit I am much more of an IC. But the way I think that should go is laddering up to business value by describing what the person did and why that contribution was important.

So for example I would say something like: X deserves a promotion because their work was important to delivering project A on time. Project A was difficult but worthwhile because it allowed us as a business to meet goals 1 and 2.

That said I mostly work in smaller orgs. I have never been in a situation where a manager would be so removed from a team they would need a sort of proxy metric to direct them where to focus their attention to understand what the people on their team are doing day to day. I can see how this would get more difficult as a company grows.

Re: The Worst Programmer I Know (2023)

#167

Post by ninalanyon »

ryandrake wrote: post #136
ModernMech wrote: post #126

Earlier quoted context omitted.

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

> every employer is basically the same in this regard.

This really isn't true. At least it's not true of companies I have worked for in Europe.

Re: The Worst Programmer I Know (2023)

#168

Post by thesuperbigfrog »

lisper wrote: post #162
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…

> who was writing the most code There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.

> Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt.

** "No Code" or Nihilist Software Engineering **

No code runs faster than no code.

No code has fewer bugs than no code.

No code uses less memory than no code.

No code is easier to understand than no code.

No code is the best way to have secure and reliable applications. Write nothing; deploy nowhere.

One of my most productive days was throwing away 1,000 lines of code. -- Ken Thompson

The cheapest, fastest, and most reliable components are those that aren’t there. -- Gordon Bell

Deleted code is debugged code. -- Jeff Sickel

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. -- Bill Gates

* Master Foo and the Ten Thousand Lines *

Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”

Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”

Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”

The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.

“And how many hours would you require to implement and debug that C program?” asked Nubi.

“Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.”

“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”

Upon hearing this, the programmer was enlightened.

Source: http://www.catb.org/~esr/writings/unix-koans/ten-thousand.ht...

Re: The Worst Programmer I Know (2023)

#169

Post by psychoslave »

lisper wrote: post #162
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…

> who was writing the most code There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.

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.

Re: The Worst Programmer I Know (2023)

#170

Post by ChrisGammell »

Atotalnoob wrote: post #129
dmoy wrote: post #93

Yea the best teams I've ever been on have always had someone like Tim. The best best teams I've been on, Tim's helpfulness osmoses onto other people, and instead of Tim always being the one, the process goes like this: 1. Dev gets stuck 2. Dev attempts to unstick self for appropriate amount of time given problem and probability of self-unsticking given resources (e.g. some stuff is easier to search for internally, or…

Problem on a lot of teams is people skip over #2 in my experience. Good devs always do #2, bad devs skip it.

Extra points for the ones that sit down at step 4 and lay out all the things they've already tried so the context on the problem is clear
Post reply on HN