Be realistic, especially if you're team lead or manager. "While the objective of the code review process is to improve the quality and maintainability of the code, the live code review ritual is rife with elements of ego and personality that can make the process quite painful for developers who just want to do a good job," says Carrier.

Avoid any sense that the review is a punitive measure, that it is about damage control, or that it is exclusively targeted toward the developers whose work is being reviewed," advises Jeff Benson, technical lead at Geneca. That's especially true with journeyman-class developers. "As coders become more experienced, reviews are often seen as invasive and doubting," says Michael Ryding, an IT solutions consultant at AXA UK.

Open-mindedness is necessary on both parts, says Smartbear's Cohen. "If the participants want the code review process to fail, they will win. It's easy to spend lots of time and find few bugs, if you're intentionally not trying."

So if you're running a code review, or are simply a participant in one, it's important to set your expectations with the right configuration. "The purpose of code reviews is to learn from one another; without detailed explanations or open discussions, no one wins," says Benny Czarny, founder and CEO of OPSWAT, which makes development tools and data services for security features of endpoint applications.

Before each session, it's a good idea to re-establish the rules (respect, humility, be constructive) and reiterate this code review's goals (relevance of design with requirements, coding standard, locate errors), suggests senior software engineer Michael Doubez.