I have worked with a number of teams over the years and from time to time I encounter developers who are very resistant to code reviews. This is normally related to some type of fear.
Some developers are fearful of having mistakes pointed out. This could be because of past experience where the review was painful and took on an accusing tone. Reviewers need to be respectful when reviewing a set of code. It should be a learning experience that provides value to the developer who's code is being reviewed.
There is also fear that with tight deadlines, the code review will add unnecessary time to an already stress filled schedule. Proper time must be included in the estimation to account for the review. In the end, time will be saved because less bugs will be found.
In rare cases, I have found developers who believe they do not need code reviews because of their experience. We need to point out that a second set of eyes will find things that were missed regardless of experience. Many very experienced developers embrace pair programming, which is in effect a continual code review.
There are some good articles that discuss the code review process.
Jonathan Lange has a nice article, Your Code Sucks and I Hate You where he points about why a code review is necessary and provides some excellent points about how to conduct a proper review.
Esther Schindler makes some excellent points in 5 Reasons for Software Developers to Do Code Reviews (Even If You Think They're a Waste of Time). Point one says that code quality improves simply because developers know their code will be reviewed. This is a perspective I had not thought of myself. There are also useful links in this article that provides tips on conducting a code review.
My message to developers is the code you write is not your personal property. It is an asset of the firm you work for and is part of something much bigger than you, a single developer. It is part of a larger product that will change the world in some way.