> I am sorry for the adjective, what I meant was "extremely incompetent"

LOL. Oh, you!

> I am taking the slightly less strong stance that a developer's LOC tells you no more about their productivity than any other random metric, e.g. the number of lines they type into Slack, the number of bugs they file in the internal bugtracker, or how many geek jokes they made that month.

Reductio ad absurdum. A new feature is expressed quite literally as code in a repository. All other things equal (i.e., if one person isn't busy with design docs, or mentoring teammates, etc) if one developer cranks out 5K lines of solid (not bloated, well-tested, etc) code in a quarter, while the other person eked out 150 lines in 3 months, that's an indicator of a potential productivity issue. How can one argue it's not even a hint of a possible problem?

> Is this person engaging at all with their teammates?

No

> Have they been active on design docs or architecture?

No

> Have they been responding to queries from sales engineers?

No

> Have they been maybe going through a big life change?

Sometimes yes. And when I find out that's why they stopped submitting code, I tell them to take the time they need to take care of themselves and their family. And we offload their work to someone else for a few weeks or however long until they're back.

> That is the crux of why I think manager who use LOC as a metric are incompetent managers. They have and project to others a simplistic view of "developer in, code out".

I wonder if maybe you had a terrible manager who was like this. Because you're interpreting my statements in the most cartoonish way possible, like I'm here saying "more code good developer, less code bad developer."

This thread started with someone saying LOC tells you nothing. I claim it tells you something, and then it's the job of the eng manager to figure out what. I totally agree that a shitty manager who literally connects LOC to productivity, is doing it wrong. But again: a good manager should be looking at the code from their team, and making sure the amount and complexity matches their expectation of what that person is supposed to be delivering.

> A hospital manager that measures staff performance by incisions per day is clearly misguided.

Wrong analogy. I have two physicians on my staff. They both have the same years of experience, the same role, get paid the same. One sees 20 patients a day. The other sees 2 a day. That's not a red flag? I should ignore that and assume that somehow every single one of their patients is 10x more difficult, and not even bother to look into it? Because if you would agree I should look into it, then the number-of-patients was a useful metric.

A metric is just data point, no more, and not a complete picture.

> If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful.

I must not have been clear. I'm not arguing for bloated code. Lean code is good, of course.

I'm talking about the all-too-common developer who has some number of tasks to complete, and tells his teammates (and me, their manager) that the work is very complex, and so they land (let's say) one bug-fix a week, giving the impression that each bug-fix (or feature, whatever) was challenging. But on inspecting their code, the code itself is fine --nothing necessary wrong with it-- but the changes are all trivial and really shouldn't take a $180K/year developer two weeks or even one to crank out. LOC isn't the full picture but it's often correlated and if nothing else, it's an obvious red flag for me to investigate.

To put it simply: If you're a high-paid engineer, you can deliver big features slowly or big tough bug-fixes slowly (and the LOC doesn't matter if the problem was actually difficult), or you can crank out lots of small features and small easy fixes quickly. But if you're barely outputting any code, and trickle out a meager amount of code, and the few lines of code you merge into the repo are all trivially simple, that's not acceptable. That engineer can't cling to "Don't judge me by my LOC!" I'm not -- I'm judging by the small amount of actual value they're delivering.