That's such a limited view which creates terrible incentives.
If you work insanely hard solving a problem, you often end up with 0 loc + an incredible amount of understanding. If you slack off all day then spend an hour writing a bunch of sloppy code, you have way more loc than someone who worked all day to refine some simple clear performant code (which is then read 500 times before it's changed, hence the time is earned back with interest).
These scenarios don't have to happen for the disincentive to still affect the work people do; there's a continuous problem from the baseline to these extremes.
It may indicate an employee with nothing to do, but in that situation would you prefer the employee did nothing, or started destroying the code base by adding KLOC of garbage to keep their manager happy and unsuspecting ?
I'm on day two of an analysis, zero code written. I don't know what, if anything, needs written. If I had to pound out something to keep from being zero it would be fraud.
The Platonic ideal of the perfect manager is still going to want to know what's going on when a report isn't checking in commits. I vigorously agree that software quality requires that developers be free to take time to analyze, plan, or just think things through, but zero code days can also indicate a blocker or a performance issue, and a manager should be helping with those.
The most valuable work I ever did, at least in monetary terms, involved zero lines of code (or certainly mergeable lines of code) for significant amounts of time while I figured out if the thing was possible, desirable, tested it, advocated for it… My manager was fine with this.
I’ve got to admit, I found this kind of _frustrating_ at the time, but if I’d insisted on writing something, anything, from the get-go, it would have been a complete disaster, and no-one would have thanked me for it.
the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people. I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out. in fact, in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist. its more like 'I talked to this person and we decided that they should merge an earlier version of their work, because otherwise I'm not going to be able to start for another 3 weeks and that totally blows our schedule'
and that ideal manager has a much better and multidimensional idea of performance over time than commit rate.
the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
> the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people.
Agreed, and this includes managers reaching out to their reports.
> I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out.
You're imputing an attitude to me which I neither hold nor intended to convey.
> in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist.
Weird. The idea that a step in a process can't be completed before another step seems bedrock to me. It's always good to eliminate these dependencies when one can, but that isn't always possible.
> the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
Considering that should be obvious, since an ideal doesn't have negative qualities, I'm forced to conclude you're responding to a bunch of things I didn't say.
