Comment by ZephyrBlu
5 years ago
Interesting. We don't track code reviews as far as I'm aware, and we use GitHub so you just get an email if you're tagged as a reviewer.
I would say it's not uncommon to have to wait a day for reviews.
5 years ago
Interesting. We don't track code reviews as far as I'm aware, and we use GitHub so you just get an email if you're tagged as a reviewer.
I would say it's not uncommon to have to wait a day for reviews.
The the first thing to do if you want to improve that is to ensure you track code reviews. Meaning, you can see what changes each person reviewed and not just submitted, and then you can use that data to talk about performance etc. If one person does all the reviews then he should get a ton of credit since that is hard important work. Typically lead programmers do more reviews and juniors writes more changes, so a person doing a lot of reviews is associated with seniority and something to strive for rather than avoid. Also I bet your manager would be interested in that information as well, so maybe you just need to suggest it to them.
There's a huge problem with this. The incentive you are describing isn't to do good code reviews. The incentive there is to do a lot of code reviews. Those two are not the same and while they are not mutually exclusive, just by tracking this metric and rating people on it, you are not giving an incentive for good code review. Only for fast review. But you really want both. You want fast and you want good and thorough.
I completely agree that senior and lead people should be doing more reviews and thus help everyone else, ultimately benefiting other programmers and the whole organization overall.
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.
1 reply →