Our approach is very simple. Each feature or bug needs to be reviewed by one person of the team, anyone with decent tech skills and enough knowledge on the lang

Our approach is very simple. Each feature or bug needs to be reviewed by one person of the team, anyone with decent tech skills and enough knowledge on the language. For such a naive approach is fundamental to teach people have to do the reviews. Our approach is try to make people (both reviewers and "reviewees") aware that reviewers are not meant to be judges. They are not meant to try to impose their opinions and ways to do things either. Reviewers can always obviously "suggest" but not mandate. So a reviewer is expected to: - Detect any fundamental mistakes that can cause severe malfunctioning like memory leaks, file leaks, bad performance signs and general bad smells. - Use his or her business knowledge to flag possible missing facts in the implementation. - Check if there is tests for the feature/bug. If there is no tests then the feature/bug is rejected. - Check that there is enough tests to cover the functionality and bug that is being addressed. - Check that the build passes and there is no regressions. So, for us, the key is to make the tests become the real low level reviewer. And the reviewer needs to focus on higher level requirements instead of going around the code checking every loop and condition. Honestly, when I do a review, I start from the tests. Those are my docs and my reviewing mates. They tell me if the feature/bug fix is realiable or needs to be reworked. Then I try to use my expertise to help the "reviewee" rather than to judge. Would love to get feedback.