> 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.