> for a whole lot of people not being able to show their productivity in a very simple way means they’re unproductive.
No, this is completely nuts! It encourages all sorts of pathological behavior to fake the metric, and throws the thing you might actually care about - business value - under the bus. It's even worse for senior people and those with architectural responsibilities. Spend time helping a junior on your team? Well, that's going to count under his commit metric and not yours, so he can figure it out himself.
My point is that if your productivity can be easily measured by LOC, then don’t tell me that LOC is a bad metric.
If your duties are mentoring, show me the meetings you had, the action items from those meetings, and what changed as a result. Nearly every job’s productivity can be showed in a pretty simple way. It’s the people who argue that their contribution can’t be simply shown that are often not that productive.
> My point is that if your productivity can be easily measured by LOC, then don’t tell me that LOC is a bad metric.
OK, so, I fundamentally disagree with the if condition.
This is in no small because of a previous coworker, in a place that shall not be named, who regularly duplicated entire class files rather than subclassing them, and his given argument when we challenged him on this was that he "couldn't subclass because the access specifiers were set to private" (yes really his defence was that bad).
Worse, I'd already added some "TODO: deduplicate this method" comments to the original, because the original was already a mess of copypasta code, and the new class duplicated all of these too.
So, a lot of new LOC that day, but none of them were good additions.
If anything that guy’s a great example of why to use LOC as a metric because when he shows you a huge number of LOC, you say, “That’s a lot more than I expected, let’s take a look…” and you see that his performance sucks.
I think of metrics like this as a way to guide deeper looks and decision making. You just have to accept that “all models are wrong, but some models are useful.” LOC can be useful when it guides you to the right questions. It’s a starting point not the end of the conversation.
No, this is completely nuts! It encourages all sorts of pathological behavior to fake the metric, and throws the thing you might actually care about - business value - under the bus. It's even worse for senior people and those with architectural responsibilities. Spend time helping a junior on your team? Well, that's going to count under his commit metric and not yours, so he can figure it out himself.