5 ms·

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

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.

BlargMcLarg 4y ago
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.
- prerok 4y ago
  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.
eckza 4y ago
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.
- dsr_ 4y ago
  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.

BlargMcLarg 4y ago

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.

prerok 4y ago
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.

eckza 4y ago

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.

dsr_ 4y ago
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.