I’ve taken a brief hiatus from blogging over the past few months, for which I can offer no excuse other than that I’ve had my head down working on an awesome RubyMotion app for a client (the banjo I got for Christmas may also have had something to do with it…). During this time, I’ve had the amazing opportunity to pair program, every day, with two senior developers at my current company, Cyrus Innovation - David A. Black (author of the Well-Grounded Rubyist), and Paul Infield-Harm, (Director of Product Development at Cyrus). This experience has led me to formulate some pretty strong views on the benefits of pair programming. I wanted to share a few of them in the hopes that those of you who find yourselves trying to justify pair programming to clients or co-workers, (especially pairing between devs of different skill/experience levels), can have some arguments to reference, or at the least, someone to blame!
Discussion and Knowledge Sharing
Pairing leads to a lot of top down discussion, from design to implementation, allowing the passenger to learn through questioning and the driver to refine and clarify their approach for the purpose of explaining it to the other person. When working out some timing issues with asynchronous calls in our app, Paul, David and I engaged in some group discussion and documentation digging about the various ways to call block arguments from nested block methods (yield vs. block.call). Had we been soloing, this exploration would have made one developer more knowledgeable. Instead, three developers, prodded by the challenges of the project, eachothers’ curiosity, and maybe even wanting to be the first one to find the answer, gained some valuable knowledge about how block arguments are handled in Ruby.
Pairing also builds confidence for both members. For a junior like me, being given the chance to drive on a specific refactoring or debugging session can be a big boost to your nascent coding confidence. For a senior developer, being asked to explain a specific concept or design decision can reinforce his/her already solid understanding of concepts and help them to move forward without apprehension. Having the confidence to express your opinions and try to implement them is a great skill to have, and pairing can provide positive reinforcement to both partners.
As a junior, one of the greatest challenges can be finding ways to explain your programming questions in an eloquent manner to people who have been doing this for years. Pairing necessitates this kind of interaction, and, as with anything else, one gets better with practice. For senior developers, getting accustomed to explaining highly technical concepts to others can be very valuable, especially in client/customer/product owner interactions, when the person you’re speaking to oftentimes lacks substantial technical know-how. In pairing with Paul and David, I was motivated to formulate my own thoughts and opinions better, which necessitated closer documentation reading and more experimentation on my own, both of which are great practice for a beginner looking to hone their skills. Likewise, I was continually impressed by Paul and David’s ability to communicate complex concepts in a clear, simple, and concise manner, the sign of true experts.
I know there are situations where pairing might not yield these same kinds of results, though I can’t help but feel that’s a product of less than enthusiastic participants or misplaced priorities. I have the pleasure of working on a team with two consummate programmers, with whom I’ve had many productive and informative pairing sessions. For this reason, I’m extremely thankful to Paul, David, and Cyrus Innovation for the experience, and more than a little wary of anyone who dismisses pair programming as inefficient or unproductive. So give it a try, and let me know if you need someone to pair with ;)