Introducing code review and pair programming has often an impact on relationships in the team - especially when a critique needs to be delivered. It takes great degree of experience on both sides to communicate defects in the code for both the reviewer as well as for the code author to get something useful out of it.

I found this at http://www.finetix.com/blogs/finetixblogs.html which can be helpful (page is 404-ing now, but I luckily saved it in Google Docs way back) :

Everyone, including me, repeat after me:

  • I am not my code. A criticism of my code doesn't have to be a personal attack on me.
  • I am not the tools that I use.
    A criticism of my tools shouldn't be construed as a personal attack on me.
  • I am not the programming language that I use

I will try to remember it (and read it to all participants) next time we get into the passionate discussion about whether inheritance or delegation is the correct approach to implement feature X :-)