Let Teams Decide on the Details
As hard as it can be sometimes to convince managers to let their teams try pair programming and see if it improves their overall productivity and quality, sometimes I have the exact opposite problem and I have managers who want to force teams to do pair programming, even when the teams don’t feel it’s right …
Continue reading “Let Teams Decide on the Details”
Read MoreTry All Configurations
Another key to discovering what works best for you when doing pair programming is to try all configurations. By that I mean mix it up as much as possible. On each project, you should try pairing with at least everyone once. Also try pairing for different periods of time before you switch pair partners, like …
Continue reading “Try All Configurations”
Read MorePut in an Honest Day
While I am a big believer in pair programming I don’t believe that we should do it all the time. Pairing is exhausting! After a pair programming session, I am usually wiped out because I am working hard the whole time. I have someone looking over my shoulder analyzing everything that I do. That’s great …
Continue reading “Put in an Honest Day”
Read MoreSwap Roles Frequently
Another important technique for engaging developers in pair programming is to swap roles frequently. For new pairs who are just starting to work together, I recommend swapping roles every 2 to 20 minutes. For more established pairs who’ve worked together well, I recommend swapping roles every 20 to 60 minutes, although that could become much …
Continue reading “Swap Roles Frequently”
Read MoreEngage Driver and Navigator
Pair programming is really a very simple concept. It’s about writing code in groups of two or more people. The person currently at the keyboard is called the driver. The person or people who are not at the keyboard are called the navigator or navigators. The driver’s job is to deal with the minutia of …
Continue reading “Engage Driver and Navigator”
Read More