Etiquette for Pair Programming
Pair programming, the practice of two software developers working on one computer together to solve one problem, is a key activity in agile software development and extreme programming (XP). Pair programming is rewarding but challenging, and it takes conscious effort to succeed. Most of the required effort can be discussed in the context of etiquette.
Here are some behaviors that can help pair programming go well:
Pay Attention and Be Engaged
Pair programming partners are a team, and nobody likes when a team member doesn’t pull their own weight. Being engaged means no headphones and minimal phone checking. And it means working on the same computer together, unless you agree that one of you will do a quick internet search for something. As a navigator, if you find yourself distracted, you should ask if you can drive for a while. Pay attention to what your partner is doing. Ask questions and offer suggestions.
Program Out Loud
Share your thoughts as you work. As a driver, don’t type long streams of code without telling your partner what you’re doing. Make sure to explain it well, or ask if you can spend a few minutes doing something and then explain it when you’re done. But keep periods of quiet concentration to just a few minutes, or your pair may become distracted. If your partner isn’t programming out loud, ask them open-ended questions like “What are you thinking?”
Encourage Vulnerability and Discourage Judgement
It takes courage to say “I don’t know” or to admit that we are tired or worried. But pairs work best when these things are out in the open. Similarly, be empathetic toward your partner, and create a space where they can be vulnerable too.
Because vulnerability is critical to successful pairing, judgements, put-downs, criticisms, and so on have no place in pair programming. Neither does mock surprise (“You don’t know what a monad is?”) or shaming.
Thicken Your Skin a Little
A common mental trap for software developers is to connect too much of our self-value with our code. Taking pride in what we do is important. But if we allow that pride to define us, then we’re likely to bristle when others critique us. Not only does this make trust and communication difficult during pair programming, but it also makes it harder for us to learn from our teammates and reduces the valuable practice of collective code ownership.
Be Humble and Willing to Try Things
As developers, we’re smart and talented, so there’s no reason to act as though we think otherwise. Humility isn’t false modesty, nor is it pretending to know less than we do. A useful kind of humility in pair programming is “strong opinions, weakly held.” This means that we operate from what we think we know, based on the information we have, but we actively search for new information to deny or confirm our ideas and opinions.
Speaking of ideas, be open to the ones your pair partners has. The best developers will suggest going with a partner’s solution first, even if they have a different opinion, because they may learn something new. After working on the problem for a while, the two of you can then assess whether you have a good solution. If it’s not, you can ask to try your idea.
Remind Each Other About Standards and Agreements
If the team has agreed to test-driven development and your partner starts a problem writing implementation code, it’s good to respectfully suggest something like, “Hey, want to write a test first?” Another good reminder is, “All our tests are green. How about we commit our code?” Remarks such as these create accountability for good development practices and team agreements.
Be a Navigator, Not a Backseat Driver
Reminders and corrections can be taken too far. There’s a balancing point that each developer pair will have to find for themselves. Instantly calling out typos and asking questions like, “You’re going to initialize that variable first, right?” can aggravate a partner and interrupt their thought process. It’s better to give them a chance to find small things like this themselves and then offer suggestions only if they don’t.
It’s like being the navigator in a car. No one likes to be told to stop at every stop sign. But when you think the driver doesn’t notice a red traffic light, that’s the time to tell them, “Uh, the light is red.”
Own Your Emotions and Be Patient with Your Pair
As humans, we have emotions and moods. And if we’re not careful, those things can spill over onto our partner. We may be withdrawn, or we may be impatient and snap at our pair.
Have the self-awareness to recognize when these things happen, acknowledge them out loud, and focus on doing better. For instance, you can say, “Wow, the way I just said that was unkind. I didn’t mean it to be. I’m just frustrated that this bug is taking so long to find.” Conversely, remember that your partner is also a person with feelings. Grant them a little slack if their emotions spill on to you. But as soon as it becomes a pattern, respectfully broach the subject with them. Try an observation like, “You’ve shushed me a couple times now.”
Take Time to Learn Each Other
Successfully pair programming doesn’t happen instantly. It will take time to learn your partners’ patterns, how they speak, and what they are good at. When first pairing with someone, expect there to be miscommunications and prepare to ask for clarifications.
Ask for What You Want, Be Prepared to Compromise on What You Prefer
If the screen font is too small for you to be able to easily read it, it’s okay to ask your pair partner to increase the size. Same goes for anything that’s getting in your way of each of you working easily on the computer. But on things that are preferences, be prepared to compromise.
One example is your text editor preferences. Do you prefer light text on a dark background? If your partner prefers or dark text on white, why not agree to their way? Or if you really dislike their preference, suggest taking turns or finding a third choice. Learn the difference between what you really need to do the work effectively and what you simply prefer.
Try Having the Less Experienced Partner Drive
This applies in general to junior/senior pairs as well as when one dev is more experienced with a particular technology or practice than the other. If you’re doing TDD, try starting out with the less experienced pair writing tests. With the rapport of humility, vulnerability, and empathy, doing something you’re not good at and having a pair coach you when you are stuck is a very fast way to learn something. Spreading learning among the team is one of the key reasons we pair program. And don’t discount the possibility that the more experienced developer can learn from a less experienced one.
Take Breaks, and Take Them at the Same Time
Pair programming is hard work. Thinking out loud, having another person looking at your work, the give-and-take of compromise—all these things take energy and effort. Be sure to watch for good times to take a break. Get up from the keyboard together, agree on a time to start again, and be ready at that time. You can spend the break with your pair, doing something like getting a beverage or taking a walk. Or you can take breaks separately, checking your phone or making a call. Neither partner should continue working while the other takes a break.
Rotate Pairs Often
Most of the goals of pair programming require frequent pair switching. Rotating pair partners causes a rapid spread of project knowledge and optimizes the chance for team members to learn from each other. Pairing together for a one- or two-week sprint is too long. On the other end of the spectrum, I have heard of teams that switch pair partners after a half day of work.
Start by scheduling pair partner switches on the same two or three days every week. Try this experiment for two weeks. At the end of the two weeks, meet as a team to decide whether to keep the rotation schedule or change it to more or less frequent.
Be Sensitive to the Fact That You’re in Someone’s Personal Space
It probably shouldn’t need to be said, but good hygiene is fundamental. We humans can be a smelly lot, and it can be hard to concentrate on code when we’re distracted by unpleasant odors, especially when sitting right next to someone. Do these things every day before work:
- shower or bathe
- apply deodorant and/or antiperspirant
- brush your teeth
- consider lunch choices without onions or garlic
- accept a mint or gum if your partner offers one—you probably need it
But beyond this, consider a partner’s potential sensitivity to smells. Some people get headaches when around a co-worker with heavy perfume. Or it could be that the leftover chicken cordon bleu you microwaved and brought over has a smell that makes you pair partner nauseous. Always think of the effect you might be having on a person you’re sitting near.
If you need to have a specific conversation about this with your pair partner, mention it to them in private. Be kind. Leave out harsh or judgmental comments like “Your perfume is awful” or “Don’t you bathe?” And remember that someone can practice good self-care and still have strong odors if they have a medical condition.
Celebrate Joint Successes
And finally, here’s an important pair programming practice that’s easy to miss. Writing software is challenging. So is pair programming. When you and your partner succeed at something, whether it’s getting a troublesome test to pass, finishing a feature, or completing a slide for the sprint review deck, it is time to celebrate!
A celebration could be something as small as a high-five or a vocalized acknowledgment like “We did great!” Sometimes just getting through a day of challenging pair programming is worth recognizing. Small celebrations such as this build rapport between pair partners and help them work better together.
Lastly, Have Courage
Courage doesn’t mean the absence of fear. Courage is being afraid and doing it anyway.
Pairing asks us to do many potentially scary things: trying something in front of someone without knowing how it will turn out, speaking frankly about differences, letting your partner try their idea when you “know” yours is better, letting go of the subconscious thought that “My code is good, therefore I am good.” Doing these and other scary things are necessary for a successful pairing. We need to have the courage to do these things even though they make us afraid. With time, they will become more natural. The courage you master in front of a one-person audience of a pair partner will serve you well when working with more of the team, not to mention in other areas of your career and life.
