Comment by kstrauser
2 years 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".
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.
> Very senior dev: ... that should take about an hour.
Red flag!
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
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.
3 replies →
[dead]