In a recent Study Group a number of us discussed an excerpt from Pair Programming Illuminated by Laurie Williams and Robert Kessler where the authors described a number of pair programming Tips ‘N Tricks.
As a group we found them to be useful. Caren was thinking that we might want to hand out the list to new hires. Perhaps you could help us refine the list: Are there any other tips ‘n tricks that you think we should add? Are there other changes we could make to the list to localize it for our environment here at Intelliware?
Tips ‘N Tricks
- Give the driver at least a few nanoseconds to find and correct his or her own mistakes. In addition, give the driver time to find menu choices before giving suggestions or correcting him or her. It gets annoying when someone continually corrects your mistakes, especially typos, when you are about to hit the backspace button yourself. Don’t second-guess every keystroke. Some people seem to be able to examine several lines visually as they are typing and constantly moving back and fixing things while they are pushing forward. Others miss the mistakes as soon as the cursor leaves the area. Be observant and adapt to your partner.
- If your partner is getting bored or falling asleep, pass him or her keyboard. If you’re getting tired, pass your partner the keyboard. If both of you are tired, try getting up, walking around, or taking a break to stop the infinite loop.
- If your partner is getting tired or frustrated, grab the keyboard. That’s one of the beauties of pairing. When you’re tired, you can be the navigator and be freed of the need to type. But, as a pair, you’re still moving full stream ahead.
- In an aim for peace and harmony, it’s good to come to an understanding of how pairing will work before getting started with a new partner. Roy Miller of RoleModel Software offers a suggestion: “One of the best tricks I’ve ever used when pairing is to start each pairing session with some ‘negotiation’. I lay out what I like and don’t like when I pair with someone, things I do well and things I don’t do well, things I need help on, things that bug me to death. Then I listen while the other person does the same. This takes less than five minutes, usually, but the results are staggering. Both members of the pair then can use the pairing session as a time to get work done and to help the other person. I think ‘pairing as negotiation’ is a key concept.”
- Ultimately, there will be conflict – on design, direction, and technique – between the partners. (If there’s no conflict, then the pairing is experiencing some other form of dysfunction.) There are several ways to handle the disagreement.
One way is for the navigator to record (on cards) contentious issues that are bothering the driver. Periodically, say every half hour, the pair should review the issues. Some of the issues may have disappeared as time passes, others may still need to be dealt with. Recording the issues on cards allows progress to be made and ensures that the concerns will be addressed in a focused debate/negotiation.
Another way of handling disagreement is for the pair to separate for a specified period of time, say ten minutes or so. During this time, each of the pair independently investigates his or her desired solution through solo programming, prototyping, or some dedicated pencil-and-paper design time. At the end of the time, the pair gets back together to discuss their investigation. With more information on each solution, hopefully the pair will be able to agree on an approach.
Wayne Conrad offers a variation of this approach. When he’s in a conflict, he says, “Just let me drive for five minutes. If you like what you’ve seen, you can drive it to completion. If you don’t like what you’ve seen, we’ll roll back and go in some other direction.” This has worked well in practice. Handing a timer to a partner is an important token. It’s saying, “I’m not tricking you into letting me drive my idea to completion; I just want to show it to you. By giving you this timer, I’m promising to quit when it goes ‘beep, beep, beep’ and then let you decide where to go next.” It’s telling your partner you are not stealing decision-making power.
Ultimately, there should be a team leader/coach/manager who resolves between partners issues that just cannot be resolved on their own.
There needs to be a balance between holding one’s ground and compromise. Be assertive without being aggressive. A partner who always gives in to his or her partner’s (perhaps adamant) suggestion, is doing great disservice to the team. Similarly, a programmer who never gives in or never gives his or her partner’s ideas a fair chance may as well not be pairing. Pairs that insist on debating every single issue are impeding progress. Chose your battles wisely; save them for issues that really matter.
- Use a coding standard. This eliminates partner disagreement due to style.
- Use test-driven development. Test-driven development is an Extreme Programming practice in which programmers write automated test cases (using a test suite like JUnit) before writing code. The idea is to write incrementally and iteratively a few test cases, then write a few lines of code to make the test cases pass. Write a few test cases; write some code. You know the drill: Lather, rinse, and repeat.
As several people have said that they really started to realize the value of pair programming once they coupled it with test-first programming. They cite that by writing the test first, both partners in the pair have a firmer grasp on the problem they are solving.
- Practice active listening by acknowledging, restating, and summarizing idea and discussion points. Be empathetic toward your partner.
- Talk a lot. Talk about what you’re doing. It helps your partner understand what you’re doing, and you might realize a flaw in your logic as you talk. Explain techniques for using the development environment.
- If your partner is just not listening to you at all, get up and walk away. This is a strong sign of your displeasure that hopefully will help your partner to see the error of his or her ways.
- Just ask! If you don’t understand what your partner is doing, then stop and ask. If you still don’t understand, ask again. Ask yourself, “When I get handed the keyboard am I going to be able to carry on doing this?” If not, ask again. “Trust me, it’ll work” is definitely not an acceptable answer from the driver.
In a mentoring situation, the mentor can ensure and enhance the understanding of the learner by asking him or her lots of questions in a pseudo-Socratic dialog; the mentor can ask good questions in order to emphasize what is important and relevant.
By asking questions, you help the driver divulge his or her thoughts at all points. This keeps the pairing more collaborative instead of one person working and one person watching. As we said earlier, in an effective pairing relationship no more that a minute should go by without some form of communication. To accomplish this, there has to be a lot of talking and a lot of asking – oh, and lots of listening.
- Take enough showers; eat lots of breath mints. Enough said.