You already know what the problem with these people is (e.g. they can take a week to add a new command-line argument). Tying that to the LOC count is counterproductive.
Shitty managers like you who try to go against the well-known wisdom and try to use LOC as a metric are what leads to the problem of shitty developers trying to game that count and posting ridiculous metrics like "I checked in 51k LOC in January". Developers who treat their work as a craft will avoid shitty teams like that even if they otherwise do well on the LOC metric.
That's rude and against HN guidelines. Don't make this personal. I'm not attacking you.
You think I'm taking an extreme position ("Managers should measure developers by their LOC"), which I am not. Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection, in the general case?
As a manager, if one person on the team is committing several times a week, and their code is, even at a glance, non-trivial, meanwhile another developer merged 3 times in the last month and the git diffs are 20 lines each, would you say that the 15 LOC a week (or whatever small number) shouldn't be a major concern that I should look into? And when this developer has been saying in every team meeting and 1:1 the last month that they've been working on tough problems. I'm not going to put them on a performance plan over their LOC, but I'm sure going to dive in if I notice a small number there, and we're going to have a conversation about it if it turns out they're not delivering.
PS: above is not hypothetical. It's happened many times in cases when I take on a new team or a developer moves under me. A couple of cases were great turnaround stories, with the developer extremely grateful that their manager was actually helping them improve their engineering. In one case the guy was let go, because he refused to accept the concept that he needed to deliver more than a couple of trivial python commits a month to justify his $250K/year salary (long story, I didn't hire him).
One of my own major wins last year was a big update to a project to strip out legacy cruft and tech debt, and scrapped maybe 5,000 LOC. The end result was smaller, faster, easier to test, and more robust. I count that as a win, by pure LOC, it was a massive failure. (Unless you don’t count code removals against an IC’s score, in which you’re optimizing for churn.)
My point is rather this, and I suppose I'm not being clear: If a developer only ever submits tiny amounts of code --and they have no other responsibilities like design docs, mentoring team members, etc-- that's an indicator of a performance problem that should be looked into and discussed with the engineer in case there's an issue.
I'm in no way suggesting that, e.g., the developer who submitted 12K LOC last year is doing a "better" job than their teammate who only submitted 11K LOC. I'm talking about that person on the team who only writes 500 lines of new code in an entire year, and they trickle out tiny simple commits ever couple of weeks. Every team that I've taken over as a manager, I find one person like this, who pushes barely any code, and the code they do push is trivial, and they aren't doing anything else either.
People here are somehow suggesting that LOC is so meaningless, that somehow apparently a person can implement a new map routing algorithm in 10 lines, or implement a new 3D rendering engine in 10 lines, or create a new data-ingestion and validation pipeline in 10 lines -- because apparently LOC is a "meaningless" number.
> slide 20 of https://www.slideshare.net/ddskier/calculating-the-cost-of-m... ("A world-class developer (e.g. Facebook or Google senior engineer) will write 50 LOC per day")
I also found some two scholarly estimates, one at 81 LOC/day and the other at 16 SLOC.
On this topic, don't forget that negative LOC can be good, as in the -2000 LOC story at https://www.folklore.org/StoryView.py?story=Negative_2000_Li... .
Sorry, I wasn't clear. I'm talking about 50 LOC every 2 weeks or so. Like, seriously low LOC of seriously low-complexity (sometimes trivial) code.
I don't actually have a numerical target people should hit. Not at all. It's more like this: on several occasions now (all too common), I've taken over management of a team, and in our initial team meetings and 1:1s, some developer talks about what they're working on and say it's really challenging but they're making progress and making progress and making progress. Then a couple of weeks in, I look at their commit history, and they've committed 6 times in the last 3 months. I give them benefit of the doubt, those must have been 6 meaningful commits. Then the first thing that stands out, the first red flag: each commit is like 25-50 lines. At this point, I have very strong reason to think we have a problem. But of course, to confirm, you look at the code itself, and one commit is just adding a command-line argument/option to a python script. Another commit tweaks some CSS. Or does a bit of dict/list operations that any developer should be able to knock out in 30 minutes.
My first hint that I need to dig in was the low LOC. Obviously, no one goes to a performance plan because they're not "hitting numbers." And obviously, someone whose job is architecture, system design, etc, isn't coding all day, so I'm not at all concerned with how much code they're cranking out. But for those whose job is, primarily, to code, well if you're writing low-complexity code (which is OK in a lot of cases) but you're writing very little low-complexity code... that's a problem.
PS: For a couple of years on my last multi-hundred-developer project, I ran a twice-yearly Code Reduction Week, and I emcee'd the All-Hands where we celebrated the developers who deleted the most code.
