I’ve known the author for many years and actually did some remote pair programming with him in early 2020 which we published as a video. I’m confident Adrian is very skilled at both pair programming and working with distributed development teams. I was pleased when he asked me to review this book and, (full disclosure), the publisher sent me a free copy.
Adrian’s advice is detailed, specific, and as the title implies, intensely practical. I won’t relate all of his advice here, of course, but a couple of things stuck out to me.
Many of us these days work in cross functional teams and any given feature might need both some Java code and some Javascript code to be written. If you have a Java programmer and a Javascript programmer, they can pair together on a Javascript task, and after an initial slowdown while the Java programmer learns some Javascript, you can expect the overall team productivity on Javascript tasks to increase. He estimates it could take 2-3 weeks of daily pair programming sessions for that to happen. Over time you can build a truly cross-functional, flexible team.
Another situation where pairing can give superior results is when you have a rather complex programming task which two senior developers work on together. If they are skilled at pair programming they will likely be able to complete this complex task faster and with higher quality than either would alone.
As a technical coach, I was particularly interested that Adrian recommends any team starting out with pair programming to have a trainer/facilitator or coach to help them. He is clearly experienced in taking that role himself. He mentions that some programmers like working alone and don’t want to pair program at all. In that case you need a good coach who will create a safe space to try it and with tact and patience make it possible for all kinds of people to learn the necessary skills and techniques. He does note that some people never take to it though. I would have liked a few more words there about what (if anything) you can do about that.
The book is structured into three parts, the first part is about pair programming generally and the second part is about remote pair programming. The third part is a kind of appendix with lots of detail about tools. When I read the first chapter in part 2 I suddenly felt like it should have been the first chapter of the whole book. It gives a good summary of almost all the topics that appear elsewhere. This was where he was persuasive about all the good reasons to do pair programming, along with strategies for when to use specific styles and techniques. I found this was the most useful part. It gave me a kind of index for looking up interesting information in the rest of the book.
Some of the detailed advice in subsequent chapters didn’t interest me very much. There was really a huge amount of advice about setting up lighting and sound and remote collaboration tools. I would have preferred Adrian to spend more time illustrating the various pairing styles and techniques. I’m still a little hazy about the difference between the Pairing-Trainee technique and the Beginner-Advanced technique. That seems to me to be advice that will still be useful and relevant when the differences between Zoom and Google Meet in early 2021 are long forgotten.
My personal advice – read chapter 4 to find out Adrian’s overall approach. Read chapter 6 to find out more about remote styles and techniques. Refer to chapter 3 for more detail on any techniques you’re less familiar with. Chapters 1 and 2 have relevant background information about pair programming in general. Read the last section before the ‘summary’ in chapter 5 and marvel at the sheer amount of technology and hardware that Adrian prefers for his personal remote pair programming setup, then read any more of chapter 5 and 7 that you need to achieve the equivalent for yourself.
