[narcindin]

How is good code review incentivized? Some ideas:

* Code review shares more credit and blame for code they approve

* Change the word "review" -> "collaborate"

* Involve the "collaborator" earlier in the process, before it's supposedly finished. If you helped write the code then the approval process will be much smoother.

* Code reviews help towards bonuses or promotions

[eyelidlessness]

I’d need to be convinced of the other three, but…

> Change the word "review" -> "collaborate"

Regardless of the word, this should be the approach. That’s what code review is: two or more people collaborating to make a change successful.

The reasons I’m iffy on the others:

> Code review shares more credit and blame for code they approve

I’m on board in spirit, but…

> Involve the "collaborator" earlier in the process, before it's supposedly finished. If you helped write the code then the approval process will be much smoother.

I’m also on board with the first part of this, but have a strong negative reaction to the second part. Helping write the code might seem like it’s more collaborative (because it is), but it weakens review because both collaborators develop shared biases/narrowed vision of the impact.

Review works because people collaborate from different perspectives. Pairing (as another comment suggests) sounds more in line with this, but I’d still want review to remain a separate process so people not involved in implementation can catch oversights by those who are involved. And I still want reviewers in a position to apply that incentive to succeed in a critical way so it increases success rates.

> Code reviews help towards bonuses or promotions

Maybe for junior devs who don’t already have the instinct to review/be reviewed? If you’re senior, part of your responsibility is to ensure that your team’s baseline expectations are being met, and to proactively try to improve the effectiveness of those expectations (whether by clarification, process improvement, coaching/mentoring, or just anticipating the need and improving it directly).

If I’m in a position to evaluate comp for a senior engineer and they’re dragging their feet on reviews, I’m more inclined to have a discussion with them about the expectations of the role than to offer monetary incentives. (And I’ll reward the positive outcomes that come with good review practices as well as all the other ways people in the role excel.)

The only exception I can really think of here is helping a team/org improve its review process overall. But that’s rewarding leadership, not personal development.

[watwut]

> Regardless of the word, this should be the approach. That’s what code review is: two or more people collaborating to make a change successful.

Nah, it is review. It is not collaboration, that is just newspeak for review. Collaboration works differently. It does not expect one person to do stuff and other to comment on in when it is expected to be almost done.

And involving that person sooner is just buying compliance here, so that review is smoother.

[eyelidlessness]

> Nah, it is review. It is not collaboration, that is just newspeak for review.

Not everything is an Orwellian conspiracy. Some people actually just think about things differently and value different things about them/in their usage. I have experienced very collaborative review processes, probably no more so than on my present team. This…

> expect one person to do stuff and other to comment on in when it is expected to be almost done.

… isn’t at all how our review process works! For even small changes, we’ve typically had a discussion about approach/design before any work begins; for larger changes a more thorough discussion about potential pitfalls and implications. We tend to have chats and review comments intermittently throughout the dev process. Nothing is “almost done” by the time it reaches review.

The thing that’s review is that typically one person is leading a given effort, and one or more people are validating it through the whole process. That is collaboration, and it’s always based in a combined effort to ensure the effort is both productive and successful.

[watwut]

> For even small changes, we’ve typically had a discussion about approach/design before any work begins; for larger changes a more thorough discussion about potential pitfalls and implications. We tend to have chats and review comments intermittently throughout the dev process.

None of that is code review. Like, literally none of that communication and activity counts as code review. Code review just does not mean "discussing design before any work begins".

[nine_zeros]

> Involve the "collaborator" earlier in the process, before it's supposedly finished. If you helped write the code then the approval process will be much smoother.

This forces collaboration on everything. Not everything needs collaboration. Some PRs just need a sanity check from a second pair of eyes. That's it.

> Code reviews help towards bonuses or promotions

Classic example of perverse incentives. This will only encourage people to comment unnecessarily on PRs, wasting the author and other reviewers time. I know this from first hand experience.

[bonniemuffin]

We include code reviews in promo/annual review materials, and actually, reviews with unnecessary/nitpicky comments on them will count AGAINST you. Submitting shitty time-wasting reviews in the packet is worse than having no reviews at all. People will actually go read all the comments you left, and judge whether they were necessary/important/improved the code.

[whatshisface]

You're heading towards pair programming.

[monkeybutton]

Also sounds an awful lot like what team leads and senior developers do too.

[bonniemuffin]

At my employer, we do "Code reviews help towards bonuses or promotions" -- we're required to include at least a few examples of good thoughtful code reviews into promotion and annual review materials.

I think it's a good policy and it helps ensure some minimum bar of code review from everyone, but it's not sufficient by itself. A person who is only motivated by the promo/review process is going to give "just doing this to check the box"-quality reviews.

I've found that people are much more inspired by all of the intrinsic motivations for doing code review, like learning from others' code and helping your teammates improve. But putting it into promo packets is a good first step to start building that culture.

[tomerv]

> Change the word "review" -> "collaborate"

A code review is not a collaboration. The author is still 100% on the hook for the correctness of the code.