- try to ask a balanced question aimed at understanding why things are the way they are. Inquire, don't challenge. This approach respects the person whose work is being reviewed and protects you against looking stupid if it turns out there is a good reason that you didn't recognize during your review.
- Don't be condescending or sarcastic. I'm a big fan of humor in the workplace, and reviews are no exception, but avoid humor at the expense of the author.
- Look for unstated assumptions. Some of the most heated arguments I've seen resulted from people who thought they disagreed, but were really working with different assumptions about the problem they were trying to solve. Recognizing assumptions and making them explicit (writing them down) is a vital skill and helps keep disagreements civil.
- Avoid proclamations; ask questions instead. A little diplomacy can go a long way toward focusing on the issue at hand without having to deal with a messy and needless "attack and defend dance." Rather than saying, "This will fail if condition X occurs," consider instead asking, "Is condition X likely to occur? How would the system behave if it did?" This approach makes finding a product's weak points a collaborative problem-solving effort, rather than a contest of one-upmanship.
- Be clear about what constitutes a "bad" idea. Is the product unsuccessful in achieving its purpose? Does it fail to meet a real standard for efficiency, maintainability, simplicity, or style (as opposed to your personal preference )? Debating style preferences can be damaging as well as futile--who cares whether you might have done something differently? If you perceive a slight weakness that is clearly not fatal, consider discussing style choices with the author offline rather than in a room full of people. Be on the lookout for peers discussing style rather than substance and do what you can to help keep the team focused on material considerations.
- Choose your battles. How "bad" is the idea? If each issue potentially escalates tensions and each escalation increases the chance that the review will derail and fail to accomplish its goals, then be judicious in your observations and prioritize your feedback based on the overall goals of the review. It's generally a waste of time to worry about spelling errors in a program's comment block when the focus of the review is to determine whether the program will work and can be maintained.
- Remember the Golden Rule: Treat others as you would like to be treated. I appreciate it when my errors are pointed out, because I care about producing quality work products. I appreciate when suggestions or criticism are offered gently, because I am a human being (despite evidence to the contrary in my early days).
Do what you can to make reviews constructive. Be clear that you are not commenting on the author when offering feedback--you are making observations and asking questions about the work product with the purpose of understanding the choices made and assuring the suitability of the work product for its intended purpose. Always seek to treat the author with courtesy and respect. Keeping this perspective in mind is a little thing that can make a big difference.
Finally, be patient and try to set a good example for any brash jerks participating in the review. With mentoring and experience, they might even become productive members of the team some day.