Comment by Jensson
5 years ago
The incentives for reviewing code should be exactly the same as the incentives for writing code.
So the most important part is that the reviewer should be just as visible in all processes and tools as the writer of the code. That way both gets recognition and both gets the blame when the code is bad or adds technical debt. And for performance reviews you don't just look at all the code they wrote, you also look at all the code they reviewed.
You are right that it is dumb to just count the number and say more is better, but the same goes for code submissions. They are very similar problems though so you can just use the same process for both of them.
And that last part unfortunately is what happens in a lot of companies. Basically taking something like your comment I replied to: "Look at metric X" and verbatim looking at that metric and only that metric (or maybe that and 2 or 3 others) and there's your performance review.
You mentioned another metric "code submissions", so say the number of reviews done is augmented by number or PRs merged. You've just created another incentive to just get a lot of code out fast.
After all, that's the point of the metrics, right? Have a few numbers that accurately describe the "value" of that employee. </sarcasm> No qualitative analysis needed, that would take time and money we don't have. Been there, had to do that (or write huge amounts of text to say why I think that this employee is actually really good at what they do and the number of PRs they did was low because they got the short end and worked on the hardest problems in the worst parts of our code base and did an amazing job especially given they were new.
If that's not how it's actually done where you work, great!