[shados]

Code reviews have 2 purpose. Help the person whom's code is being reviewed improve quality/catch issues, BUT ALSO the reviewer gets familiar with the code being pushed and learn stuff. It's super important for new engineers to review code as soon as possible for the later.

[jolmg]

> BUT ALSO the reviewer gets familiar with the code being pushed and learn stuff.

The reviewer is supposed to determine what goes in or not, so how can this be an opportunity to learn from what goes in? They're the one who's supposed to determine that! Is your idea of a reviewer someone who just spectates all code going through? It's like saying people who don't know a subject should grade work from students taking a class in that subject, as it's a great opportunity to learn from what gets turned in.

[BeetleB]

>The reviewer is supposed to determine what goes in or not

This is not a given, and in fact, I would not recommend it.

For small code reviews with only one reviewer, the reviewer gives feedback and they have a conversation about it, but with only one reviewer the developer should have the final say. The problem with giving the final say to a single reviewer is you'll get plenty of pointless code changes to suit the reviewer's individual preferences. Don't waste time on what is a perfectly reasonable difference in opinion.

If you have more than one reviewer, but still a small code review, the final say should be with the reviewer(s) - if their is consensus (you could also go with voting, with its pros and cons). Having multiple reviewers prevents the likelihood of individual preferences dominating.

If it's a significant code review, the final say should be with an experienced moderator.

[tkxxx7]

> The reviewer is supposed to determine what goes in or not, so how can this be an opportunity to learn from what goes in?

You specify multiple reviewers. That's it.