23 January 2007 - 17:08Tips for Pair Programming

I’ll start off by saying I am a big proponent of pair programming. It’s a very effective programming style when used in moderation. I read stories about some places that pair all of the time for everything - while I’ve never worked in that kind of environment, I can’t imagine it would be too pleasant. There are too many programming activities that involve “think time” in which you’re not talking, not typing, not reading, but simply processing. Depending on the kind of work you’re doing, this think time may be a big or small part of your day, but either way it’s an important part.

However, pair programming is great for some tasks. Lately I’ve been pairing with a colleague to hammer out the finishing touches on a feature for an upcoming release, and pairing to do this is working really well. Along the way, I’ve done a few small things to make the overall pair programming experience as effective as possible.

Environment
If you’re going to be pair programming for any length of time (more than an hour or two), getting the environmental factors right is crucial. Pairing in a noisy environment isn’t as effective as pairing with fewer distractions. At the same time, realize that pairing creates a fair amount of extra noise in the environment that wouldn’t otherwise be there (especially if you work in an office environment), so be respectful of your non-pairing coworkers.

A clean and open work space is a must. Both programmers have to feel comfortable - if your counterpart has to dig through last week’s sandwich wrappers and who knows what else in order to find a place to work, you’re probably not going to have an effective pairing experience. If you will be doing some extended pairing, spend some time before you start cleaning up your work environment. By reducing the amount of clutter and having clean work surfaces, your pair will feel much more comfortable and willing to invest in the effort.

Along these same lines, consider closing programs which pop up intrusive notifications for the duration of the pairing session. This includes things like mail readers and feed readers that have the habit of popping up temporary windows to alert you of new items. This will only distract from the pairing session and your pairing partner probably doesn’t care to see the notifications anyway. If you’re worried about missing important mail, just take a 10 minute break every couple of hours and check for any urgent messages then.

Another point is that you need lots of collaboration material. At a minimum this means a large, clean whiteboard with plenty of markers and an eraser. It’s surprising to notice the psychological effect of a whiteboard that’s been freshly cleaned with whiteboard cleaner compared to one that’s dirty and lightly erased with a felt eraser. Also good to have on hand is plenty of pads of paper and pens for jotting down quick notes and diagrams.

Input Devices
Ideally pair programming doesn’t work like drivers ed. Each participant should be just that - a participant and not an observer. It’s great that you can show off your mad programming skillz to your pairing partner, but that isn’t really the point of the exercise. The ideal pairing setup involves dual everything - 2 keyboards, 2 mice, and 2 monitors. In my case I had only a single monitor handy but there are plenty of extra mice and keyboards laying around, so I plugged in a second set of input devices and we were off to the races.

The ability to have both pairs able to code without having to play chair tetris or keyboard shuffle saves a lot of time. Often this means one of the programmers can pick up in the middle of a block of code where the other left off, and you don’t have to context switch at all. This also means that you’re not bumping elbows when trying to scroll around through a class (personal space is important to many programmers :)).

If you are going to use only a single monitor, be sure to position the monitor so that it can be easily seen by both. Often this is a different position from what is optimal for a single programmer so don’t be afraid to slide the monitor around when starting the pairing session to find the best spot.

Of course it goes without saying that you need to have two comfortable chairs and plenty of space to sit in. If you want to go all out there is always the PairOn. :)

Fonts
A prerequisite for this kind of extended pairing session is to increase the font size in the tools you’ll be using together. This is less of an issue if you’re using multiple monitors, but it’s still important to consider it. That 10 point font you use with your 21″ 1600×1200 monitor doesn’t look nearly as good when your face isn’t 4 inches from the screen. In Eclipse, I set the text font to be Consolas at 14pt, which works great for pairing off of a single monitor. Consolas looks great on LCD monitors with cleartype enabled, and if you are legally allowed to install it on your machine I can’t recommend it enough. Of course, the downside of larger fonts is that you can’t see as much code at a time, but it means that you don’t get eyestrain or headaches and both programmers have a good view.

ZoomIt
Finally, I highly recommend installing the ZoomIt utility from Sysinternals on the computer before beginning the pairing session. This utility was written to help aid presentations, but it’s perfect for pair programming.

ZoomIt has two extremely useful features for pairing. First, with the press of a hotkey, you can use the mouse wheel to zoom in on any portion of the screen. Even if you’ve bumped up the font sizes as I suggested above, there will probably still be times that a little zooming is needed to narrow in on something. If you or your pairing partner need to often lean closer to the monitor to try to read something, ZoomIt will be a huge help.

Secondly, ZoomIt has a great annotation feature that allows you to draw on the screen. This can be great for pairing - instead of smudging up the screen every time you need to point out something, simply press a hotkey and use the annotation feature instead. This is a really underrated feature for pairing - how many times have you wanted to point at a section of the code or highlight a particular block? Again, this feature is all hotkey driven and the ZoomIt utility overall is very well done.

Conclusion
Keep in mind that pair programming can be mentally draining. Often a 6 hour work day pairing is easily the equivalent of an 8 hour work day alone, especially if you don’t pair often. When done right, you can temporarily boost your effective output, but when done wrong, it can be an excuse to slack. Also I’ve found that during pairing you will often discover tasks that one or the other of you need to do, but doing those tasks as a pair would be a waste of time. The best thing to do is to keep a list of “action items” that are related to the task at hand but will be completed outside of a pairing session. If you do this, be sure to put appropriate TODOs in the code and keep your parter informed about the progress of your action items.