Obviously, if management buy into spending time with code reviews, then everyone has to do it.
But there are always those guys (or gals) who resist with every ounce of their being.
How do you effectively manage dealing with this scenario when dealing with it as the peer reviewer?
He resists because of fear. This conditioning may be the result of previously bad experience(s) about being reviewed, as a kid, at school, at work or even in your current team. In our modern societies, it's very common for us to confuse someone's work output with his value as an human being. That why reviews at work are not well perceived. That's also why speaking in public in one of the most spread phobia (fear of judgement).
To avoid such behavior, you will need some psychology. You must prove to his lizard brain it's not going to happen (he won't be judged, humiliated, killed, anything...) by desensitizing him to code reviews.
One of the most effective method I found to unblock someone is to ask him to review your code, before asking to review his code.
After a while, propose him to read his code to learn from it and why not suggest improvements. When you find something to change, be careful in what you write. He will understand there is nothing to be afraid of, and he will take the positive part of the reviewing process only: learning and increasing his knowledge.
I'd try working in pairs - team someone who hates the idea with someone who likes it, and have them review each other's code for a couple weeks. Obviously this may or may not help, but being on both ends of the review will at least give a more rounded view of the process. Having a pair work together will allow them to get familiar with each other's style and common mistakes and will give them time to actually help each other get better, rather than rubber stamp. This can also help you promte pair programming in your work environment, as I think you may see a growing tendency to not only review, but recode or even plan and code from scratch.
As long as the disinterested parties are willing to try, this could help. If they refuse to consider it, there's not much you can do about it as long as they are on the team.
@Pierre's answer is right on track for someone who fears a code review. I can imagine another situation. A star programmer who feels a code review is a waste of time because there code reaches an acceptable standard of quality and correctness. In this case they may feel a code review is a time waster and a witch hunt. (That is a search for a problem when none exist.)
In this case I would re-orient the goal of the review. Instead of the code review being about finding "problems" in the code, treat it as a search for re-factoring targets or potential future enhancements, or additional design features. In this way, both the coder and the reviewer are involved in the process and hopefully this able coder will feel like there time is being put to good use.
Frankly, this question doesn't make any sense if you have a well managed shop:
1) If it's part of the job, you must do it, or you're insubordinate. Someone who adamantly refuses to do part of the job they are required to do should get canned. Programming is a craft and a profession - reviewers and managers are there to help get the job done, not deal with spoiled kids (of any age.).
2) If you have a well managed source control system, (which is a must in any professional software shop), then their code can be reviewed whether they like it or not. So review their code:
If it's good, notify them and give them a pat on the back - that will encourage participation.
If it's no good, also let them know. This should have the effect of motivating them to participate, in order to defend themselves. If it doesn't, you can use punitive measures: Financial penalties, demotions in status, etc. If in spite of your efforts this employee fails to come around, IMO you have a bad employee and they should be shown the door.
Do they have some negative experiences at places where code reviews were not done properly? They may have legitimate concerns.
If they absolutely see no merit to the exercise, ask them to be patient and see what happens to their code and especially other's (if they they think are perfect) as a result.
Code Review 'should' improve development, but until you have a system that actually works, why should anyone want to do it?
I personally that there are some fights that just can't be won with 100% of the population.
I can see enough reasons why pair programming wouldn't work when someone is forced to do it.
But code reviews are different - they change your productivity, not necessarily your work habits.
Management can do several things to reduce resistance due to productivity: 1) Accept the reduction in speed for all developers. 2) Furnish appropriate tools to deal with the management and merging of multiple versions due to review cycles (e.g., allowing developers to have a local git repository) 3) Enforce some social or other form of pressure to ensure distribution of load and quality and timeliness of reviews.
If they do that, it's legitimate to require everyone to participate, IMHO. The company I now work for forces this globally - you simply can't submit without an owner's approval. And while this slows things down, it prevents a lot of accidents.
We used technical measures to make code-review mandatory.
The way we introduced code review is that in in our source control, it's impossible to merge code that's not been signed off by someone else then the one who pushed it.
