4

Cracking the code review (Part 4): Conflict management – Andy G's Blog

 3 years ago
source link: https://gieseanw.wordpress.com/2020/06/25/cracking-the-code-review-part-4-conflict-management/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Conflict management – Andy G's BlogSkip to content Skip to menu

(This is the fourth part in a series about working effectively to pass code review quickly and without missed defects.)

In the last post, I discussed how proactively involving your reviewers in your design and implementation process would get your reviews approved faster. The biggest risk of proactivity, though, is that one or more reviewers might disagree with you.

If we don’t manage arguments properly, things will come to a head at review time when your reviewer is free to let loose all their criticisms yet again. Then you’ll reply in kind, and so on.

Time spent going back and forth in a code review is wasted time.

You can’t logic your way through an argument

Let’s operate under the assumption that you are right and your reviewer is wrong (because you’re always right, right?).

As developers, we are logic-oriented people. The computer doesn’t care about emotions, only cold-hard logic. So if you just presented a well-reasoned argument backed up by references, your reviewer will have no choice but to agree with you, right? Frustratingly, the opposite is true [1].

How many doomsday cults simply move the date of the apocalypse or reinterpret current events as a sort of end-times when the day of their prediction comes and goes? When confronted with irrefutable contradictory evidence, their beliefs were only strengthened*.

*There is an excellent documentary called Behind the Curve where you can witness Flat Earthers do this exact thing when their experiments only continue to prove the earth is round.

Okay so your reviewers probably aren’t part of a doomsday cult, but the point still stands. This is the theory of cognitive dissonance. When presented with information contrary to their views, people are more likely to disregard that information rather than change their opinion [1].

Paradoxically, challenging someone’s beliefs with evidence may only serve to strengthen those beliefs [2]. So what can you actually do when a reviewer disagrees with you?

1. Downplay the importance of the belief

Research shows that less closely-held beliefs are more easily changed [3], so try to convince the reviewer that it just doesn’t matter that much whether you use encapsulation or polymorphism. Besides, if time shows that your code is not flexible enough, you’ve written adequate tests such that it can be easily refactored (you wrote tests, right? right?).

2. Dodge disagreement from the start

Image source: Wikimedia

An even better strategy is to prevent the reviewer from forming the wrong belief in the first place.

I once worked with a reviewer that seemed to disagree as a reflexive action. The first way I preempted disagreement was by proactively involving that reviewer in the design. I simply presented the problem in such a way that the obvious solution was one I had secretly already decided was best. I was very gracious when that reviewer "invented" the same design I did.

One time I took it so far as to present the opposite of what I thought was a good idea, just because I knew they would disagree out of habit. Call me underhanded, but it worked.

3. If all else fails, agree to disagree

I’m not saying you should silently seethe and move on. I’m saying that if you have a reviewer that ultimately disagrees with you and the rest of the team about the best approach, note their disagreement and then ask them to review in spite of it!

For example

Once I was tasked with architecting a new feature for a subteam to work on over the next few months. I spent a week rigorously researching the topic. Then I prototyped a few different implementations before I settled on a design I was happy with. And then the team lead promptly threw most of it away in favor of a design he had in his head.

I was a little perturbed, and I voiced my concerns as best as I could, but the team ultimately agreed upon a design that was fundamentally different than mine. One thing the team did well, though, was acknowledge my protestations and have me agree to review in spite of them. In the end the work turned out pretty well, and the client was satisfied.

The team could have easily missed deadlines if I blocked review after review because I disagreed with the overall design, but that did not happen because they effectively got buy-in from me at the onset.

In conclusion

I’ve been fortunate enough that the vast majority of my colleagues have been easy-going people that handled conflict well. Ultimately conflict resolution is not about "winning" or "losing", but understanding and empathizing.

Perhaps the senior dev you work with has been burned so much on the default int type not being the expected number of bits that they defensively use int32_t. Maybe the new dev was simply taught that Big-O was the be-all end-all way to choose an algorithm. Try to understand why they have the beliefs they have before passing judgement in a review comment.

The main takeaways from this series

In case you weren’t taking notes while reading this series, here is the 30,000ft view:

  1. Mistakes made during review can cost big $$$ down the line
  2. Reviews should be small or at least feel small
  3. Reviews shouldn’t contain more than 4 "things"
  4. Shoot for around 10 minutes total review time
  5. Write code aimed at your audience, not yourself
  6. Be explicit
  7. Use familiar patterns
  8. Proactively involve you reviewers in design and implementation
  9. Have a meeting for large reviews
  10. Resolve conflicts long before a review happens

The end

Thanks for reading. I hope you feel more empowered to breeze through your code reviews. Please leave a comment or shoot me an email (found on my About me page) if you found any of these techniques useful, or have any criticisms.

If you ever find yourself in the reviewer’s seat, I highly recommend How to do code reviews like a human and How Google does code reviews.

References

  1. Festinger, Leon. A theory of cognitive dissonance. Vol. 2. Stanford university press, 1957.
  2. Gal, David, and Derek D. Rucker. "When in doubt, shout! Paradoxical influences of doubt on proselytizing." Psychological Science 21.11 (2010): 1701-1707.
  3. McLeod, S. A. (2018, Febuary 05). Cognitive dissonance. Simply Psychology. https://www.simplypsychology.org/cognitive-dissonance.html. Retrieved May 2020.
Advertisements
Report this ad

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK