Pair Programming - Keep an Open Mind
When we’re asked to think about a programmer, a rather unfortunate image that springs to mind for many people is the lone wolf glued in front of their computer, Monster Energy drink within arm’s reach, frantically typing their night away, unwavering in their solitude. Of course those of us who have had the pleasure of being part of the development industry, or fraternizing with others who have, know that that’s not an accurate representation of most of today’s programmers. More than ever, collaboration is a big part of any developer’s career. As applications grow in size and complexity, we developers are increasingly expected to be able to work and cooperate well with others.
To that end, pair programming is a technique often proposed for fostering collaboration and improving the quality of code. It involves two people teaming up to write code on one computer, either in person or remotely. The first person, designated the driver, controls the keyboard and mouse, and performs all of the input to the computer. Meanwhile the second person, the navigator, provides commentary and direction while observing. The latter tends to have the broader picture of the program in mind, and they’re responsible for catching mistakes made by the driver and ensuring a dialogue is maintained. It is generally recommended that the driver and navigator switch roles at regular intervals.
Is it Worth it Though?
But wait, if two people are committed to one computer, doesn’t that mean that half the amount of work will be done? Wouldn’t productivity be maximized if the two were working independently on their own branches of the project? Indeed, this is an oft-raised criticism of opponents of pair programming. Nevertheless, proponents of the technique maintain that the benefits are numerous, and that in some cases the performance is superior to the combined performance of the two individuals working separately.
In what ways can pair programming help in the workplace? With the constant attention given by the navigator, mistakes are much less likely to make their way into code, resulting in overall better quality. Consistent coding and style conventions are more likely to be followed with pairs learning each other’s habits and encouraging each other to follow best practices. Moreover, this technique lends itself to the transfer of skills, especially as more junior-level developers are able to pick up on techniques and habits of their more senior-level colleagues. A greater level of confidence and satisfaction can be achieved in the code as a result of pair programming.
It should be mentioned that this type of working is not for everybody. Just as we all have different ways of learning, pair programming is not a one-shoe-fits-all scenario. Many people simply do work better alone, preferring any peer review to happen at a later point.
Doing it the Right Way
Assuming the benefits however, there are ways of approaching pair programming that almost certainly guarantee people will have bad experiences. Failing to actively communicate in the pairing can greatly reduce the overall ability of the team to work. Being overly competitive or too ego-driven can also quickly put a damper on the experience as any or all given feedback gets rebuffed. These situations can lead to tension in the pairing, reducing team effectiveness and even worsening workplace atmosphere. Having the wrong mindset going into pair programming sets it up for failure from the start.
It is therefore be prudent for individuals to adapt their mindset before beginning a session of pair programming. Being open to feedback and willing to have your ideas challenged is vital in this scenario. On the opposite end, it is an invaluable skill to be able to give polite and constructive feedback, and therefore careful consideration should be given to this approach. With a little bit of preparation, you can increase the likelihood that you and your partner will experience the benefits of pair programming while reducing the drawbacks.
I have experienced both the ups and downs myself. I have been in pairings where communication was sparse and where progress was not being made, and in those moments it was difficult not to wonder if we would have simply both been better off proceeding on our own. However, I have also had extremely positive experiences with pair programming where my partner and I had great chemistry and were able to fill in the gaps for each other. This latter experience left me feeling content and inspired. It left me a proponent of pair programming.
Pair programming may not be adored by everyone in the development community, but it is hard to deny the potential advantages it brings to the table. Whether you’re a lone wolf star programmer or a super teamwork collaborator, I encourage you to engage in pair programming from time to time - as long as you’re willing to be challenged, that is.
For Further Reading
- The Collaborative Software Process, Laurie Ann Williams.
- The Benefits and Pitfalls of Pair Programming in the Workplace, Sam Harris
- Pair Programming, Agile Alliance
