Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Probably the same way you deal with people who take issue with other items like dress code, timeliness, sick days, etc. – Josh K Jan 25 '11 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 Jan 25 '11 at 14:41
Honestly: Tell them to shut up and do it. It's for their own good. – Steve Evers Jan 25 '11 at 14:47
up vote 41 down vote accepted

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.

share|improve this answer
You might want to add a definition for "lizard brain" for folks unfamiliar with it. – Adam Lear Jan 25 '11 at 14:44
@Anna: I just added the link to a definition. – user2567 Jan 25 '11 at 14:45
Awesome answer Pierre! Upvoted for now in lieu of a final answer. – ozz Jan 25 '11 at 14:48
@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 Jan 25 '11 at 15:00
As usual an excellent answer Pierre. – Josh K Jan 25 '11 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.

share|improve this answer
Pair programming is a whole other topic, but great suggestion! – ozz Jan 25 '11 at 14:58
Your commented got me thinking some more about PP, so I started another Q -… Thanks! – ozz Jan 25 '11 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.

share|improve this answer
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 Jan 25 '11 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.

share|improve this answer
That is completely hopeless advice, i foresee a "shop" with really bad work environment for you. Urgghh! – cognacc Jul 3 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 Jul 12 at 14:21

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?

share|improve this answer
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 Jan 26 '11 at 8:35
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 Jul 12 at 14:24
@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 Jul 18 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 Jul 20 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.

share|improve this answer
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 Jan 26 '11 at 8:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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