My experience implementing software with Pair Review
My experience implementing software with Pair Review
What is Pair Review technique? what are the benefits and the challenges that brings?
In November 2023 I wrote an essay about my experience using the Pair Programming technique to improve the code quality of the software. You can find the link 👇🏻
Lately, I’ve been experimenting for 3 months in my team with the Pair Review and, in today’s issue, I want to share with all of you my experience on it. We will cover:
What is Pair Review
The benefits that Pair Review brings
The challenges to consider
What is Pair Review
As usual, I will not give you the official definition but my definition and focus on software development.
Two or more persons are reviewing the code written by other/s.
That’s the general idea but too wide, so let me put some details that I believe make this practice more effective.
Implement some code. Get some piece of code that solves a functionality as you would have to ship it to production. Once you are happy, join your reviewers to the show.
Review the code with your reviewers. The developer/s that create the code should be present in the Pair Review, either acting as a compass or just being there for clarifications.
Perform the changes immediately. If possible, and timewise, the owner of the code should perform the changes suggested (and agreed upon) by the reviewers before continuing with the rest of the session. If not, the owner should take clear notes, provide the change as soon as possible, and iterate again on the Pair Review.
How do I use to use this technique? What I do is that, when I have some code implemented, with the proper shape that would required to launch it into a normal Code Review (via Pull Request for example) I just schedule a 30-minute call with my team. In that session, I share my screen and I go through the code as a compass so the reviewers can focus on provide direct feedback. I implement the changes live as well, with my reviwers present, unless the change is too big.
One thing I see important is the fact to perform Pair Reviews over a Pull Request or commits not delivered yet into production. This will transmit the aim that the code is willing to change and adapt, to have a better quality based on the feedback of the reviewers before shipping it to production
At this point, we should have an idea about what this technique is. Now, let’s go into the benefits I have seen so far.
The benefits that Pair Review brings
As I mentioned before, I’ve been using this technique for 3 months, and I can see some benefits that I share with you now.
Improve code quality. This technique is meant to improve the code quality when the code reviews could represent a complex and long-term task.
Transfer knowledge. We want to avoid silos as much as possible, but this could happen even within the same dev team. Having Pair Review sessions will help to spread the knowledge about the change/s that the software the team owns.
External point of view. If you can include, as a reviewer, someone who is not from the team that owns the code that is changing, you can get great benefits because that person will not be tainted by the code style of the rest of the team; another point of view.
Immediate feedback. I find a lot of value of having immediate feedback about my code changes. In a Pair Review session is a great moment for that because you have the context and feedback live. What is more immediate than that!
Developers’ growth. When developers work together we exchange and learn together. Things that I’ve never considered others did so I can learn from them and they from me. I would advice to ensure your junior profiles are involved on this.
Not everything is gold and shiny. There are no silver bullets and, because of this, let me share with you now some challenges that I found.
The challenges to consider
There are some:
The calendar of code owner and reviewers. As many times, one of the major challenges is to handle the agendas for the dev team. Quite often they are buried under too many meetings and this Pair Review might perceived like that. For this, it’s important to reinforce the message that Pair Review is to get feedback and improve the code that the whole team owns, and not only for “everyone to be on the same page about the code”.
The Pair Review session should be scoped about the number of persons. A wide audience will go against of the goal of the Pair Review session, having too much noise, and taking the risk of get stuck in some endless discussion.
Avoid interrupting your peers. All of us are very busy and the focus time is something sacred so, be kind and not jump into the Slack chat to bring them immediately when you have your work ready. Instead, books the proper time so the interruption can be avoided.
Not needed if you are doing Pair Programming already. I did not see much more value of doing Pair Review when my team and I were doing Pair Programing as well. Unless your software is really critical, the majority of important things will be tackled with your pair already, at least, from my experience.
Summary
Let’s wrap up the issue for today! Here some takeaways:
This is a good technique when you cannot work in Pair Programming and when the code change is complex.
It’s, as Pair Programming, better than async code reviews.
Ensure you do not bother too much your team but, instead, schedule the sessions, make the sessions predictable.
Try it! it’s not expensive thing!
Hope you enjoy! Do you have experience with Pair Review or other techniques to improve the quality of the code? share it the comments! I would love to read them!
Best,
Marcos
Pair Review is the faster way to review medium/large changes.
Sometimes, I go further, and we work together to tackle the feedback in the same session.
Well said, Marcos.