story
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).
I am sorry for the adjective, what I meant was "extremely incompetent". That is still harsh, but hopefully conveys my opinion regarding your grasp of management in a more objective manner. It's not meant to be personal, I would say the same thing about someone attempting to use the OCaml compiler to run a Python program, and telling me that's how they do things at their daily job.
> 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?
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.
> 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?
Is this person engaging at all with their teammates? Have they been active on design docs or architecture? Have they been responding to queries from sales engineers? (a lot of time at an old job was literally telling Sales "yes, our product can do that"). Have they been maybe going through a big life change?
Without all of these, it's not possible to get a complete picture of why there is a problem. And a lot of them are more specific and better questions to ask than "how many lines were in the diff?"
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".
> 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).
Since you have shown precisely this in your post (e.g. you didn't say anything about his lack of design or documentation or engagement with teammates; all of which I would certainly expect at that level), I think you need to reexamine your worldview, or at least the way in which you present it.
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.
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.
If you think LOC is a useful metric, I would disagree that someone calling this "bad management" is attacking you. 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.
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.
Teams of people build things. LOC don't add up to a hill of beans.
I think maybe you haven't seen how unproductive some people can be. And one hint of their productivity, is that they don't have much code to show for. If someone can explain to me how they're writing significant amount of new software with less code than this comment I'm typing right now, I'd be interested to learn how they did it.
