Pair Programming Tactics
The Agile Zone is brought to you in partnership with JetBrains. Discover how to increase change awareness, code quality, and maintainability through straightforward code reviews, with a simple, lightweight workflow.
1. Just Talk
Whether they are programming in pairs or by themselves, developers should always talk or "think out loud." Self-talk and conversation with another person is beneficial to the speaker and not just the listener. It forces the speaker to focus on examining their questions and it helps them answer their own question. The listener can also think more deeply when the speaker talks about their ideas out loud. Chatting back-and-forth is the primary way of bouncing ideas off one another and sharing knowledge. It's also very helpful if the two programmers perceive each other as knowledgeable or "experts", because that will cause each person to ask deeper questions and challenge themselves to meet the "expert's" standards.
2. Two Heads are Better than One
In almost any kind of work, it's hard to catch your own mistakes. When writing code, you notice your mistakes less because what you notice depends on what you expect to see. A second pair of eyes will look at your code differently and more often catch your mistakes and offer suggestions. They will also catch mistakes faster and make development more agile. One thing to watch however, is the effect of prolonged pairings between the same programmers. If pairs can rotate their team members, they probably should. When two people work together for a long time, they start to notice or not notice the same things, which defeats the purpose of having different perspectives.
3. Pair Pressure
Novices (and even experienced programmers sometimes) that do solo programming tend to engage in ineffective practices like code-and-fix. With code-and-fix, the programmer just tinkers with the code, runs it, and repeats the process. This will yield unpredictable results and gives no real understanding of the forces at work in the software. Pair programmers will be less likely to slide into this kind of behavior if they set standards for each other, either implicitly or explicitly. The subtle pressures of pair programming can help developers kick those bad habits once and for all.
4. Determine Experience, Yours Included
The productivity of one programmer can often be very different from another programmer. Developers can't predict the difficulty or time requirements that someone can handle until they start working together. When working with a team of pair programmers, rotation is especially helpful here too. By comparing yourself to other developers, you can accurately judge their capabilities as well as your own. The team will also figure out who knows the most about certain things and the team will know where to direct their questions on certain subjects. One other important part of pair programming is doing it side-by-side. If two programmers can easily communicate during their sessions and literally point things out on the computer screen, a lot more information can be shared. Just remember, your screen should be covered in oily finger-marks, otherwise you're not doing it right.