[hakunin]

I don't honestly know why most people do code reviews, because it's often presented as some kind of "quick sanity check" or "plz approve". Here's why we do code reviews where I get to lead the practice:

1. Collaborate asynchronously on architectural approach: (simplify, avoid wheel reinvention)

2. Ask "why" questions, document answers in commits and/or comments to increase understanding

3. Share knowledge

4. Bonus: find issues/errors

There are other benefits, like building rapport, getting some recognition for especially great code.

To me code reviews are supposed to be a calm process that takes time, not a hurdle to quickly kick out of the way. Many disagree with me however, but I'm not sure what the alternative is.

Edit: people tend to say reviews are for "bug finding" and "verifying requirements". I think that's at best a bonus side effect, that's too much to ask a person merely reading the code. In my case, code reviews don't go beyond reading the code (albeit deeply, carefully). We do however have QA that is more suited for verifying overall functionality.

[kevmo314]

I've found great benefit in voluntary code reviews. Engineers are self-aware enough that if they're at all worried about a change working they will elect for a voluntary code review. As a reviewer I also feel like my opinion is more welcomed because I know someone chose to do it instead of being forced so, so I pay more attention.

This really gets at the benefits you mention and keeps people aligned with them instead of feeling like code review should be rushed.

[tomasreimers]

This.