Follow

Follow
Sharing context outside pair and mob programming

Sharing context outside pair and mob programming

Approaches to avoid the pain of Async Code Reviews.

Tiger Abrodi's photo
Tiger Abrodi
·Nov 13, 2022·

2 min read

Table of contents

  • Pre-review
  • Pair reviews
  • Conclusion

I dislike Async Code Reviews. They are time-consuming, and numerous times have I found myself being confused because I don't fully understand the entire context. I don't like them, they are a pain, and really slow down the team.

This was one of the greatest write-ups I have read about Async Code Reviews: From Async Code Reviews to Co-Creation Patterns. It also goes in-depth about the pros and cons of both big and small pull requests.

In this article, I want to share ways to reduce the pain of Async Code Reviews, but not directly doing pair or mob programming.

Pre-review

Before a task gets implemented, the engineer that will be implementing it chats about it with a teammate. This way they can come to an agreement on how it will be implemented.

Once it is done the two persons come back and do a pair review if possible.

If that isn't possible, the reviewer can review the code asynchronously, and if any changes are necessary, they can also take over the pull request (collective ownership). Most of the time from my experience this results in an immediate merge.

I said changes necessary because a pull request shouldn't be blocked over minor things.

If things are working, the requirements have been fulfilled, no risks are involved (performance, security...), and the code is well-tested, then get the pull request merged! Refactorings can be done in follow-up pull requests.

Pair reviews

If doing a pre-review isn't possible, I recommend scheduling a time to do a pair review.

A focused session where the two persons involved (author and reviewer) review the PR together and any changes that should be made, they do it together, and get the PR merged, no ping-pong and annoying cycles which often happen in Async Code Reviews!

I like this approach. The only con here is that the reviewer still needs to learn the context involved and if major changes need to happen to the code for whatever reasons, then the pair will get it done together, although that could have been avoided with a pre-review.

Conclusion

Async Code Reviews are painful. Pair and mob programming aren't the only alternatives to avoid the pain of pure/traditional Async Code Reviews. There are other ways to avoid doing them and become more productive as a team!

 
Share this