Pair… Code Review?
I discussed the value of pair programming with friends recently. A lot has been written on the topic, but I realized that I have an interesting experience with a less mentioned tool: pair code review.
If pair programming doesn’t work for you for any reason, you can still do better than the usual code-review-comment-fix-repeat loop. Here is a personal account of my experience, the pros and cons, and when I would use it.
Making the most of pair programming
Pair programming has been an established practice with many benefits (even some less obvious ones like keeping the WIP low). I usually find most of the value in three things: knowledge sharing, making better design decisions from the start, and getting unstuck faster.
The knowledge-sharing aspect is strongest when working with new people. That’s when we can learn the most from each other, get exposed to our different experiences. Beyond fixing typos or simple errors, we can share the reasoning behind our design choices, discuss the underlying principles we follow, exchange productivity tips, … Even with colleagues I have been in the office with for a long time, I often don’t get the feeling that I really know them until our first pair coding or debugging session, and it helps to build mutual respect.
The knowledge sharing advantages diminish over time, however. We have fewer new inputs to exchange. The better we know each other, the better I can simulate the other’s opinion in my mind and predict what I will hear during a code review. In a way, I have a little virtual colleague in my head I can pair up with.
This has happened to me several times. Looking back, though, I learned the most from a really smart colleague who never liked pair programming. How did I learn so much from him?
Pair code review
My colleague preferred coding alone but he also disliked electronic tools for code review. He would write his code review notes down on a tiny sheet of paper and then we would sit together and he would guide me through the review notes — all the things I missed, poor design choices, opportunities for improvement, etc. This was exactly the opportunity where we would discuss our guiding principles, productivity tips, and everything. And the next time I would do the same for him.
It felt just like pair programming, just more compressed, limited to only what deserved the increased attention. In some regards, it was even better — when you are forced to tackle a problem on your own and then get feedback, you often learn more than if you are guided through every step. And over time, this was enough to reach the state where I absorbed his know-how and could hear his voice in my head when I was making design choices.
Another important practice was that we wouldn’t just explain the review notes, we would go and fix things together — in a pair programming session. This prevents the frequent cause of long lead time when the code review bounces back and forth in several rounds.
In short, pair code review often gave us many of the benefits of pair programming in less time.
What I don’t mean by pair code review
I should emphasize that by pair code review I don’t mean inspecting the changes (pull request) together. I have tried that too but never found it effective. The pressure of the author’s presence interfered with my concentration and depth of inspection.
The traps
Of course, there are hidden traps and many ways how not to do a pair code review. Probably more so than with regular pair programming.
Late feedback
The most obvious problem is that getting feedback late can be very inefficient if it means rewriting a lot of code or you no longer have the willpower to change a poor design choice.
Not everything is lost, though. The reviews should be done frequently, preferably on small pieces of code. Most importantly, we learned to reach out for advice early and often whenever we got to a decision that might be difficult to change.
It requires a certain level of maturity, trust, and understanding to discern the right questions and time to ask. Disrupting the flow is a factor; on the other hand, juniors are often too hesitant to ask for help when they get stuck on a problem (and that’s where pair programming can really save loads of time).
Openness to feedback
Trust and openness are also important to accept a constructive critique and change one’s mind after the code is finished, otherwise, the effect of pair code review will be strongly reduced.
Sloppy code review
Conversely, the reviewer must not be afraid to speak her mind and point out things that are worth changing or discussing. The coder and reviewer can rely too much on each other without making it explicit and let problems slide unnoticed.
When to use pair code review
As a rule of thumb, I have a higher preference for pair coding until we get to know each other really well, harmonize our approaches, build trust, and learn when to ask to get unstuck. Then as advantages of pair programming for daily work diminish, I would transition to pair code review.
I would prefer pair programming with juniors (though not all the time) and new team members, when starting a new project, or to bounce ideas off each other when trying to crack a tough bug or problem.
I would prefer pair code review when I know the colleague well enough to know what to expect, especially if pair programming is not so practical, e.g., because we have a too different pace of work. Alternatively, you may find pair review useful to ease colleagues with an aversion to pairing into pair programming.
Summary
By pair code review, I mean a practice where the reviewer inspects the code, then sits together with the author, and guides the author through the review comments, fixing them together.
I don’t mean to argue that code reviews are better than pair coding. I’m trying to say that in situations where pair coding is not the best option, we can do better than just regular code review — and pair code review can go a long way.
Even though it is not a practice that’s mentioned a lot, I’m glad to have it in my toolbox. I invite you to experiment and see how useful it is for you.
