[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".