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?

  • 19
    Probably the same way you deal with people who take issue with other items like dress code, timeliness, sick days, etc.
    – Josh K
    Commented Jan 25, 2011 at 14:38
  • hehe.... I tried to qualify that by the bit about management saying everyone has to do it, what I'm looking for is when you the lowly peer reviewer has to try and get it done.
    – ozz
    Commented Jan 25, 2011 at 14:41
  • 3
    Honestly: Tell them to shut up and do it. It's for their own good. Commented Jan 25, 2011 at 14:47
  • 1
    Resisting what? Letting you see their code or them looking at yours? They may be avoiding conflict, can they expect conflict? Do you know why they are hesitant? Commented Oct 19, 2016 at 12:12

7 Answers 7


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.

  • 3
    You might want to add a definition for "lizard brain" for folks unfamiliar with it.
    – Adam Lear
    Commented Jan 25, 2011 at 14:44
  • @Anna: I just added the link to a definition.
    – user2567
    Commented Jan 25, 2011 at 14:45
  • Awesome answer Pierre! Upvoted for now in lieu of a final answer.
    – ozz
    Commented Jan 25, 2011 at 14:48
  • 1
    @Aaron: I was refering to "someone" mentionned in the question. Yes I've still irrational fears due to conditionning in both my child and adult life, like most of us. Examples: I've an irrational fear of highs. I'm desensitizing myself when I can. Last weekend I visited a citadel (very common in my country because of successives war between frenchs and germans) and had to take a areal tramway.
    – user2567
    Commented Jan 25, 2011 at 15:00
  • 1
    As usual an excellent answer Pierre.
    – Josh K
    Commented Jan 25, 2011 at 15:06

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.

  • Pair programming is a whole other topic, but great suggestion!
    – ozz
    Commented Jan 25, 2011 at 14:58
  • Your commented got me thinking some more about PP, so I started another Q - programmers.stackexchange.com/questions/39878/… Thanks!
    – ozz
    Commented Jan 25, 2011 at 15:46

@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.

  • 5
    With this type of person, you could try letting them know that you are excited to review their code because you think you will learn alot from them. Code review isn't only about the code being improved but about exposing others on the team to better code which will help them in future development.
    – HLGEM
    Commented Jan 25, 2011 at 20:18

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.

  • That is completely hopeless advice, i foresee a "shop" with really bad work environment for you. Urgghh!
    – cognacc
    Commented Jul 3, 2016 at 14:48
  • @cognacc - You needn't 'forsee' anything. I have been working in groups for 25 years where we have a very good work environment: We're all adults and understand what it requires to be professional and to have accountability for our work.
    – Vector
    Commented Jul 12, 2016 at 14:21
  • 1
    I have to agree with Vector. If it's part of the process, everyone does it and I'm sure they quickly see that "it doesn't bite". There's always a risk of some people being "rude" in their comments in a code review, of course, but then it's those people that need to be dealt with - just like they would be if they were rude to their coworkers in person. Commented Oct 19, 2016 at 12:01
  • I agree with cognacc, it is useless advise because it does not suggest a strategy or solution. It just says "they must because they have to". Duh. The question is how to deal with them, as in how to turn them around. Just making people do something against their will (or else) is not fixing the problem, it is likely creating new ones. You must first understand the origin of the resistance. Commented Oct 19, 2016 at 12:45
  • You missed my remark well managed shop and all that follows therefrom: That means you're dealing the adults: People who know what their job means and entails. You failed to comprehend my abundantly clear answer.
    – Vector
    Commented Oct 20, 2016 at 16:22

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?

  • Thanks Jeff, agree, if the process is no good, it'll be difficult, and getting around anyone's irrational fears can be difficult - some people just won't change!
    – ozz
    Commented Jan 26, 2011 at 8:35
  • 1
    but until you have a system that actually works, why should anyone want to do it? Let me take a wild stab at this: Do it so you can figure out why you're system isn't working?
    – Vector
    Commented Jul 12, 2016 at 14:24
  • 1
    @Vector - If you're programmers can't figure out how to make it work, they may have bigger problems. I also think management has to take some responsibility and make a clear definition of quality code. If the code that is getting released doesn't have too many bugs, they may have a good reason not to include code review. For a project of any kind of complexity, I doubt that is happening without either quality code review or possibly a disproportionate amount of development time and cost.
    – JeffO
    Commented Jul 18, 2016 at 2:59
  • @JeffO - OK, I see your point: If the system really doesn't work, it's not the question of "code review", the question is programmers' competence, and so simple "code review" is not the solution. I agree with that.
    – Vector
    Commented Jul 20, 2016 at 17:09

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.

  • totally agree Uri...there are just some people you can't win over. Maybe they are set in their ways, lazy, think their way is correct, or just plain don't care!!
    – ozz
    Commented Jan 26, 2011 at 8:36

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.