Comment by choeger | Hacker News Reader

Comment by choeger | Hacker News Reader

But he didn't write -2000 lines of code, did he? He wrote a new algorithm that was 2000 lines shorter than the old one. So, in principle, there was a positive number of lines that could have been reported.

Of course, loc is a bad goal for productivity, but it can still be an interesting measure (similar to test coverage): If I count lines of code added, commits, or tickets closed, I cannot compare any two developers. But if I count that metric for the same developer, or the same team, I can certainly spot changes in productivity. (As every metric has its outliers it would probably be. best to combine all of them.)

So if I was managing a team and wanted to know if it would be beneficial to optimize test execution times, I could just rent some bigger machines and see what happens. I could also do a similar experiment with organizational aspects like the size and schedule of meetings or the introduction of a dedicated on-call contact for support requests, etc.

No, you can't. There is barely any correlation between the amount of new lines of code I wrote in a day and how productive I was that day.

As a senior technologist who bills his time as a consultant, I can tell you that I (correctly) get paid the most for days where I write 0 lines of code.

But also, my most valuable code was code where I spent a week thinking and writing maybe 5 lines of code a day, and my least valuable code was when my output was limited by my typing speed.

Alternative proposal: Count the number of commits devs are making. Since some devs make more frequent commits than others, for each dev review some fraction of their commits at random, and rate how substantial the randomly sampled commits are. Then multiply average commit importance by number of commits to get an overall productivity score.

Thoughts? I think the biggest counterargument is that it incentivizes churn like making a commit and then reverting it later.

Your ratings are going to be somewhat arbitrary and the moment this comes out, you'll risk Goodhart's Law anyway.

Besides, you might as well start counting closed number of issues/tasks/tickets, story points or whatever, and skip the commit count altogether.

Yeah, and that has another problem: developer who code fast but don't think things through would have plenty of issues opened against their code. They would probably be fixing them as well so their close count would be much higher than for a programmer that made the right choices to begin with.

You could then go with features only tickets but those vary in size and complexity. Now, if we would put complexity as a measure (on which the team of developers should agree) and then measure the number of issues on that implementation we might get a better measure of that person's contribution.

That said, once that would be in place, even that can be gamed.

I think there is no silver bullet here, as much as we would like it to exist.

Alternative proposal: for the love of God, please stop trying to quantify this.

If your engineers truly aren't getting shit done, you should be able to tell without looking at their code.

We don't get paid to write code. We get paid to _think_; it's just that if we don't write code afterwards, we get fired.

Programming is the reification of decision making processes.

Therefore, a language that allows a programmer to turn thoughts into correct code faster is a win.

The size of the code as writter is only slightly interesting: almost everyone can type faster than they can think clearly. A more compact notation is preferred for reducing the delay between typing and testing, but not to the point of impairing readability.

> As a senior technologist who bills his time as a consultant, I can tell you that I (correctly) get paid the most for days where I write 0 lines of code.

What do you do then?

He helps a company to increase revenue or decrease expenses -- or at least that is the expectation of those approving his consulting fees.

Maybe convince management not to rewrite their core system.

Or listen to the requirements from a new system and propose an existing tool that solves 90% of them. Or explain why the library they were going to use solves a different problem and how they'll regret choosing it.

Or talk to folks and figure out why my proposed new design for a system doesn't cover all the needs of the old one (and eventually that some iteration of it _is_).

Or sketch possible algorithms for a difficult problem on a whiteboard / notepad until I figure out a good-enough solution.

Or talk to stakeholders about their needs and concerns regarding a new system I'm helping design.

Or talk to customers. Or help prepare a pitch or customer demo.

It's very rare that a customer feels it's worth paying me rate for writing code. Though it does happen, and when it does it's usually very interesting code with a very interesting story behind it.

    >But if I count that metric for the same developer, or the same team, I can certainly spot changes in productivity

I can't imagine this working in any scenario. Even different tasks within the same project on the same day will involve enormously different amounts of coding, testing, and analysis.

> If I count lines of code added, commits, or tickets closed, I cannot compare any two developers. But if I count that metric for the same developer, or the same team, I can certainly spot changes in productivity.

No you can't.

Sometimes I will be working on coding related tasks for months, and then mostly on design tasks for months. I am not more or less productive in either, but I will close a lot less tickets and write 0 lines of code when I'm doing design-related work.

Same with oncall. I probably won't write much code but I can close a hundred tickets in a week.

Metrics are just a stupid measure of an engineer's productivity.

Reply on news.ycombinator.com