Mindful code reviews

I really enjoyed Alex Hill’s lightning talk on the Art of Giving and Receiving Code Reviews Gracefully a couple of weeks back at the Lead Dev London conference. Short, to the point, and compelling.

A couple of slides really stuck for me.

First, Alex suggests that different types of code review comment can be placed along two axes:

A chart of different types of code review comment

Comments that can cause conflict, but result in changes that are ultimately low value should be automated away (yay linters and automated code formatting) so they don’t even come up in code reviews.

Low conflict items tend to be more factual - e.g. bugs. These can also be automated to a certain extent, but again they naturally shouldn’t take up much energy during code review.

Finally, it’s the high-reward and high-conflict comments that can benefit from improved communication and collaboration.

There are different styles and strategies for dealing with conflict:

Conflict resolution archetypes: avoiding, yielding, competing, collaborating and compromising

Each individual may have a typical approach, or may use different strategies at different times for different topics and with different people. I know I’ve used and continue to use all these strategies, for better or worse.

Alex explains that the aim for code reviews should be to lower defensiveness and raise confidence so that most conflicts are resolved through collaboration.

This effort can be helped if you aim to reduce the need, impact and surprise of code reviews. After all, they happen once work has been done, so authors are more likely to be defensive of their work, and reviewers are more likely to avoid conflict and conveniently ignore bad implementations for a quieter life.

The earlier this collaboration take place, the better. Try to agree an overall approach before work starts. Identify reviewers in advance. Reduce the surprise by pairing. Don’t silo contributors and reviewers into skill set buckets. Make sure all code is reviewed and that everyone reviews code.

Alex goes on to some excellent advice about using positive language and some tactics for keeping reviews healthy for everyone.

How can you help to improve your team’s code reviews?

All the best,

– Jim

Receive emails like this in your inbox

I write about front-end engineering leadership every weekday.

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.