26

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 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
  • 3
    Honestly: Tell them to shut up and do it. It's for their own good. – Steven Evers Jan 25 '11 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? – Martin Maat Oct 19 '16 at 12:12
46

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 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
  • 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 Jan 25 '11 at 15:00
  • 1
    As usual an excellent answer Pierre. – Josh K Jan 25 '11 at 15:06
5

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.

4

@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 Jan 25 '11 at 20:18
2

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 Jul 3 '16 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 '16 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. – MetalMikester Oct 19 '16 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. – Martin Maat Oct 19 '16 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 Oct 20 '16 at 16:22
1

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 Jan 26 '11 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 Jul 12 '16 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 Jul 18 '16 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 '16 at 17:09
1

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 Jan 26 '11 at 8:36
0

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.

-1

Fire them

It's that simple -- either they get a lone-man project, or they have to go. Get them away from your team. They are not only not doing their part, they erode team morale and practices.

Now, if it seems you have to fire 50% of your team, then...

Understand

Why some refuse? Do they have no time? Are they burnt out? Are reviews about something they have no experience with? Do they think it's a waste of time, if so why?

Agile methodology will help here -- I'm assuming your constantly work against silos (i.e. to reduce bus factor), and individuals in your team are involved in what others do.

Work to ensure individual merge requests are quite small. If it's more than 1 screen of changes, it needs a stand-up or lightning talk to explain what is being done. If it's 10 pages, it needs a presentation with slides and architecture diagrams.

Does everyone in question work on the same project?

Is the project already buried under mountain of technical debt?

Do they believe in the project and continuous improvement?

  • 1
    Hmmmm....so not believing code reviews provide more benefit than cost automatically means a person is not doing their part and eroding team morale, so much so that they should be fired? That's a rather bold stance based on no evidence definitively supporting the claim. – Dunk Oct 19 '16 at 18:08
  • @Dunk, are you an anti-reviewer? Then you won't be on my team. Are you a pro-reviewer? Then you already know support to my claim. Are you undecided? Please make up your mind ;-) – Dima Tisnek Oct 20 '16 at 11:36
  • I am not an anti-reviewer but I also recognize when something is not providing reasonable benefit relative to the cost. Some projects/teams absolutely need official code reviews while other projects/teams only do them when its deemed beneficial. Your assumption that code reviews are always required tells me that you don't even know the real benefits and limitations. So you are right. I won't be on your team and that'd be a big loss for you. – Dunk Oct 20 '16 at 21:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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