Two heads are better than one, and by extension two developers are also better than one. The concept of pair programming is simple, it’s two people using a single workstation to work on the same piece of software together. Let’s take a look at how pair programming can help your team be more efficient, while having more fun at work!
Developing software can be split up into two distinct activities: there’s design and there’s coding. Every developer must be capable of doing both, but when working in isolation they must do both at the same time, and we all know that the human brain is really terrible at multitasking. Pair programming aims to break those two actions into two separate roles: the driver and the navigator.
The driver is the person with their hands on the keyboard, they are writing the code. They are responsible for implementing the design and making sure the code is syntactically correct. On the other hand the navigator is responsible for higher level design and directing the driver. While the driver is writing the code the navigator watches to look for bugs or for better ways of implementing whatever the driver is working on. Together they form a synergistic pair that is simultaneously designing and writing code.
It is expected that the pair swaps roles frequently, while the driver is writing a piece of code the navigator should be thinking about the next section of code to be written. They can set a timer, wait for the driver to finish a section of code or even switch randomly. In any event the pair shouldn’t stay in the same role for any more than a few minutes.
A sign that the pair are not performing well together is that one person is monopolizing the driver role. This can happen when a junior developer works with the senior developer and they don’t feel confident or comfortable at the keyboard, they prefer to let the master do it. In this case it’s up to the senior person to insist that the junior takes over the keyboard at regular intervals.
During a pair programming session, the two developers should be constantly communicating, discussing a particular implementation, weighing alternative methods and even doing some immediate low level design work. Another sign of an underperfoming pair is they are both sitting there in silence. This is the core benefit of pair programming, both developers must be fully engaged together, two heads are only better than one if they are communicating and sharing ideas. If the driver runs into problems they should ask the navigator for help. And conversely if the navigator doesn’t understand what the driver is doing they should definitely ask for clarification.
Sounds quite chaotic doesn’t it? When working together the desk and workstation must be set up so that passing the keyboard back and forth is quick and easy, and both developers must be able to see the monitor(s) equally well. For example a corner desk is terrible for pair programming because the navigator probably can’t read the monitor as well as the driver. And switch roles requires the two to move seats in that case. Ideally a wide desk or table can be used with the monitor placed between the two, or with enough space so that they can roll their chairs slightly when switching access to the keyboard.
If there are multiple developers on the team then create a matrix or spreadsheet to track which developers have paired together. This can be used to uncover which people work well together and which don’t. It can also serve to spread out the knowledge of more senior developers. Pair programming provides an on the job training method to cross train developers so make sure that they all work together in pairs at some point.
After team building the next best benefit of pair programming is that the resulting software has fewer deficiencies. With two sets of eyes on a piece of code being developed, each developer will apply their own critical thinking to the project. They can be more confident in their resulting software, and a more confident developer is a more productive developer.
Once a piece of software is written using pair programming, both developers have a clear understanding of the intricacies of how it works. They can now both take ownership of the software and trade off fixing any deficiencies that may come up later.
Have you used pair programming to develop software? I’d like to hear about your experiences, both positive and negative. Please leave a comment below.