Hacker News Reader

Comment by pdimitar | Hacker News Reader

Since when delivering 10x more code is objectively a better performance?

If we're talking about point samples, then no, it's not a good measure of performance. You may spend weeks fixing a single line in the kernel, meanwhile someone else cranks out hundreds of lines of verbose but straightforward UI code every week.

And also, we can all imagine a developer who cranks out gigantic commits by padding their comments, or just being verbose, or writing bad complicated code, or even just by moving code around to get big commit numbers. I'm not talking about that.

I'm saying, if you compare apples to apples, and look at a long time horizon (i.e., look at the total of an engineer's contributions over 6 or 12 months), then I claim that yes, generally speaking, there will be a correlation between productivity and LOC. I don't see how it could be otherwise. Software is code.

Edit: Hopefully it's clear that above only applies when comparing a pure-developer to a pure-developer. If your job also includes code reviews, writing design docs, etc, then obviously your LOC goes down.

I completely agree that using a median LOC over 12 or so months is much more representative. My point was that many times, especially when you are a senior programmer, you have a ton of other stuff to do like making or curating issues in Jira / GitHub, produce or edit documentation, make onboarding guides, introduce dev tooling, and many more. Normal coding can seriously take a back seat for literal months when you are senior and yet you still produce a lot of value.

So yep, with your clarification I am fully with you. As long as we measure people over a long enough timeline then yes, LOC can be an accurate metric. But a lot of other things have to be taken into account as well.

Perhaps not objectively, but PRs will often be reviewed during performance review season. So seeing someone at 10x less than someone else is a major red flag, as long as the quality of PRs is roughly equal.

I get where you are coming from but I still disagree that we should try and game the system like that. Instead our peers and CTOs should grow the "realism" brain lobe.

This hits even closer home to me because I am about to get evaluated this Monday and my PR performance has been pretty sub-par in the last 3-4 weeks -- I've been put in a project that has been abandoned for like 3 years and only recently picked up again and 90% of what I do is documenting and taking notes and creating GitHub issues; coding is sadly still a low priority activity because there's still chaos.

But you know what? I don't care anymore. Let them fire me if they use broken metrics. I am doing my work very diligently and I am making sure the project will be in a better shape after me. If they can't appreciate that then I am not bothered by such people viewing me negatively. They are in the wrong, not me.

LOC is just one within many signals your manager and organization should use in their review. If you have low LOC because the project was in chaos, or was still being designed and organized, etc... those would all be fine justifications to me as a manager. In fact, those would be problems for me to solve -- to make sure you are in an environment where you are able to be productive.

If, on the other hand, you were on a "smooth sailing" project, and didn't have any code delivered in the last month, that would be a red flag to me, which we would need to talk about.

I agree with that, yep.

Reply on news.ycombinator.com