Pair Programming techniques
Pair programming has been widely touted as a effective means of generating excellent code in a cost-effective manner. It has also been widely reported as a waste of time or as uncomfortable. Many people reject pair programming without trying it. Others, however, still don’t like it after
being forced to use trying it.
I’m convinced that there’s an art and a science to pair programming. I don’t think it comes naturally to most people. It’s sometimes easy to pick up by osmosis, but I’ve heard too many complaints about pairing to think that’s a common occurrence. I’d like to hear your real-life stories about pair-programming situations. If you don’t feel comfortable leaving your story as a comment on this blog, send them to “pairprogramming at idiacomputing.com”.
I also think there are specific techniques that make pair programming work better and go easier. One example is the “10-second rule.” The navigator should wait 10 seconds before pointing out a typo. Generally that’s long enough for the driver to correct a typo that’s already noticed. Excessive interruptions are distracting.
Another technique is for the driver to “think out loud” as she’s coding. This helps keep the navigator in the loop, and communicates the intent better. It’s certainly not a technique that most people practice without suggestion, however.
I’d like to hear of techniques that you’ve found effective, also. As mentioned above, send to “pairprogramming at idiacomputing.com” if you don’t feel comfortable posting them in public.