Continually experimenting with new ideas and techniques — Reconstructing, Developing, Modernising.
Only a few days ago I read Paul Hinze’s Pairing vs Code Review blog post, and it gave me an opportunity to reflect on some recent experiences.
In one context I use gerrit to review code, and there isn’t much pairing. The pairing is done using screen and a Skype voice channel over a sometimes laggy VPN. Development in this context feels very episodic, and the feedback loop of submitting the code for review and getting the review can be quite long. There are lots of context switches, and much of the time I feel like I’m working at crossed purposes with the tool — maybe I am, and need to learn more about gerrit. A benefit of the “delays” is that it gives a little distance, and the opportunity to look at the code with fresh eyes when considering the review comments. Quite often I let myself succumb to getting the first hack “clean enough” for a “work in progress” review, yet I feel like this review is more final than it really is. The time between submitting and feedback is often long enough to get sidetracked by other urgent-seeming tasks.
In another context I am either physically co-located with a pair, or use a tool like screenhero to provide a decent voice channel as well as a graphical screen where both participants can be active. This is used on projects where github is the source control and review system. In this environment I find that I do a lot more experimentation and find it easier to discard ideas. I think it is useful to have someone who wasn’t involved in the development do the pull request’s review, and I believe that the quality of the code submitted for review is better after pairing.
I don’t feel they are mutually exclusive choices, I do feel that pairing nourishes one part of my soul and reviews another.
That’s just my 2¢, and I’m looking forward to pairing up with a buddy at home tomorrow as a prelude to a beer!