4 ms·

I dislike the just-so aspect of these sort of stories. I'd expect exceptional programmers to do unusually well on most metrics. But that is balanced by the thr

by roenxi 3y ago

I dislike the just-so aspect of these sort of stories. I'd expect exceptional programmers to do unusually well on most metrics. But that is balanced by the threat of people trying to use metrics to measure developer productivity. It doesn't seem to be possible, any metric falls apart. If people are focusing on a metric, the greats aren't going to be leading any more. It'll be some junior who has misunderstood the system and has accidentally trained themselves to game metrics. Metrics do not drive good software. Repeatable processes love metrics. Repeatable software suggests bad development practices because that is a big hint of a library or bigger opportunity that nobody on the ground properly identified.

kstrauser 3y ago
> I'd expect exceptional programmers to do unusually well on most metrics. ...when they're actually hands-on-keyboard writing software. The best programmers I know write as little code as possible. Product team: Hmm, we need to do a thing that looks very complex and difficult. Senior dev: I'll start making a project plan and story breakdown. Very senior dev: That sounds like a special case of a thing we already have. That should take about an hour. Of course that's a generalization, but I think the trend holds. The most illustrative metric for the best engineers wouldn't be "lines written" but "lines avoided".
- OnlyMortal 3y ago
  In my experience, the best programmers write the least amount of code they can get away with. I don’t mean they use the latest fashion library, I mean the amount of code they type is less simply because they understand the problem and know how to write a minimal solution. This makes their code easy to read and therefore easier to debug. It’s worth noting that the less you type, the fewer bugs you’ll create. To be fair, this is often due to the coder having significant experience.
- Fluorescence 3y ago
  > Very senior dev: ... that should take about an hour. Red flag!
  - nevertoolate 3y ago
    Why do you say red flag? It is an exaggeration, of course, nothing is purely 1 hour. Rather it is 1 hour work in flow state, which is about 2 pomodoros, which is about 6 bulletpoints, which is about 1/4 of a day’s programming effort. Just about right for a 1 point card by a senior who only sit down to code when they kinda exactly know what to write
    - ChoHag 3y ago
      [dead]
    - Fluorescence 3y ago
      Talking about flow state and estimates? The red flag just gets bigger. You are asking me to show you that Santa is not real. A "very senior dev" will not be handing out "1 hour" estimates to a product team. An hour of what? Billable hours? Wall-clock time? It's just not the right framing. You will notice a good senior dev will be incredibly cautious about any commitment and not hand out "ego estimates" like one hour. They will make commitments that they can keep and it will be terms of releases. They will have experienced a decade of "one hour jobs" that have exploded so they know that even the error bars on a slam dunk 1 hour of butt-in-seat time means it's not a 1 hour estimate. An hour of butt-in-seat coding time is not a 1 hour of employee time - they've got that training course, those interviews, they need to support that thing, oh the presentation, the intern to look after. That feature you are copying? What is it copy-paste or some refactor generalisation? Measure that shit in weeks. Oh and there are 6 feature branches overlapping that area already. You also have a policy to improve the tech debt of this crusty code. There is also the documentation, training material, translations, the test suite, code review, the issue tracker... But hey, you can do it, you are x10, you boot up your machine and... your IDE is crashing because of some security update. Doesn't count in that one hour eh?! That's not even the main issue, odds are the first over the shoulder demo of this new feature will be just the start of eliciting the real requirements.
      - kstrauser 3y ago
        That sounds nightmarish. If I say 1 hour, I mean that I know exactly which knob needs to be twiddled, perhaps because I wrote it in the first place, and that there'll be a pull request ready for review an hour from now. That's clearly not always possible. Sometimes it is. If I say that it is, then I can deliver it.
eesmith 3y ago
> I'd expect exceptional programmers to do unusually well on most metrics. Not if they game the metrics, as a way to force change. A classic example of an exceptional programmer doing worse on a (bad) metric is at https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li... , titled "-2000 Lines Of Code". "Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. ... Bill Atkinson ... thought that lines of code was a silly measure of software productivity. ... [He] made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code. ... when it was time to fill out the management form ... he thought about it for a second, and then wrote in the number: -2000. ... after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied."

by roenxi 3y ago

kstrauser 3y ago

> I'd expect exceptional programmers to do unusually well on most metrics. ...when they're actually hands-on-keyboard writing software. The best programmers I know write as little code as possible. Product team: Hmm, we need to do a thing that looks very complex and difficult. Senior dev: I'll start making a project plan and story breakdown. Very senior dev: That sounds like a special case of a thing we already have. That should take about an hour. Of course that's a generalization, but I think the trend holds. The most illustrative metric for the best engineers wouldn't be "lines written" but "lines avoided".

OnlyMortal 3y ago
In my experience, the best programmers write the least amount of code they can get away with. I don’t mean they use the latest fashion library, I mean the amount of code they type is less simply because they understand the problem and know how to write a minimal solution. This makes their code easy to read and therefore easier to debug. It’s worth noting that the less you type, the fewer bugs you’ll create. To be fair, this is often due to the coder having significant experience.
Fluorescence 3y ago
> Very senior dev: ... that should take about an hour. Red flag!
- nevertoolate 3y ago
  Why do you say red flag? It is an exaggeration, of course, nothing is purely 1 hour. Rather it is 1 hour work in flow state, which is about 2 pomodoros, which is about 6 bulletpoints, which is about 1/4 of a day’s programming effort. Just about right for a 1 point card by a senior who only sit down to code when they kinda exactly know what to write
  - ChoHag 3y ago
    [dead]
  - Fluorescence 3y ago
    Talking about flow state and estimates? The red flag just gets bigger. You are asking me to show you that Santa is not real. A "very senior dev" will not be handing out "1 hour" estimates to a product team. An hour of what? Billable hours? Wall-clock time? It's just not the right framing. You will notice a good senior dev will be incredibly cautious about any commitment and not hand out "ego estimates" like one hour. They will make commitments that they can keep and it will be terms of releases. They will have experienced a decade of "one hour jobs" that have exploded so they know that even the error bars on a slam dunk 1 hour of butt-in-seat time means it's not a 1 hour estimate. An hour of butt-in-seat coding time is not a 1 hour of employee time - they've got that training course, those interviews, they need to support that thing, oh the presentation, the intern to look after. That feature you are copying? What is it copy-paste or some refactor generalisation? Measure that shit in weeks. Oh and there are 6 feature branches overlapping that area already. You also have a policy to improve the tech debt of this crusty code. There is also the documentation, training material, translations, the test suite, code review, the issue tracker... But hey, you can do it, you are x10, you boot up your machine and... your IDE is crashing because of some security update. Doesn't count in that one hour eh?! That's not even the main issue, odds are the first over the shoulder demo of this new feature will be just the start of eliciting the real requirements.
    - kstrauser 3y ago
      That sounds nightmarish. If I say 1 hour, I mean that I know exactly which knob needs to be twiddled, perhaps because I wrote it in the first place, and that there'll be a pull request ready for review an hour from now. That's clearly not always possible. Sometimes it is. If I say that it is, then I can deliver it.

eesmith 3y ago

> I'd expect exceptional programmers to do unusually well on most metrics. Not if they game the metrics, as a way to force change. A classic example of an exceptional programmer doing worse on a (bad) metric is at https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li... , titled "-2000 Lines Of Code". "Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. ... Bill Atkinson ... thought that lines of code was a silly measure of software productivity. ... [He] made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code. ... when it was time to fill out the management form ... he thought about it for a second, and then wrote in the number: -2000. ... after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied."