bugs is good, not bad. Never stigmatize or single out a developer who made a mistake, make it informal. Have people adapt to code review -- help your peers accept it, not fear it. Code Review can not only be useful -- it can be fun as well. Remember that more time and more difficult tasks equal more bugs -- the number of bugs does not indicate a developer's skill! If you're a manager or team leader, make sure no one sees code review as negative or a waste of time. Make sure they don't see it as a rule enforced by the company but as an improvement to their everyday workflow which they should keep regardless of the company they work for. Whenever possible, strive for a personal approach of code review. If you're using tools, use them in OTS as well. The personal approach of mutual brainstorming and informal discussion of potential solutions to problems is invaluable in the process of accepting code review as your friend. In Conclusion Code review can be incredibly difficult to implement, especially in a team of old-timers who aren't used to it. But once done, it will not only decrease the number of defects in your code, it will also increase collaboration and help team building, improve "brotherhood" amongst developers and will propagate best practices and improvement of skill across an entire team or department. Any type of code review is better than none, so if your team isn't using it today,