Pairing is the EXtreme Programming (XP) software development in which two developers work together sharing one computer to design code and test user stories. There are many great guides on pairing effectively both in-person and remote, guides on equipment suggestions, and many more. There are, however, far fewer guides on how not to pair, or more accurately what are habits/mindsets that will hamper your pairing experience. I have organized these into three categories: engagement; discipline and unhelpful dogmatism; and interpersonal interactions.
Pairing involves two people working together for an extended period, this is most effective when both people (pairs) are engaged in the task at hand. Engaged here means focused and fully concentrating on their specific story or task. When fully engaged the pairs can consistently get into a state of deep work (also referred to as “Flow” or “The Zone” in sports. For further study I would recommend Cal Newport’s book, Deep Work). To maintain extended periods of focus it is important to minimize distractions, this section goes through a few common distractions I have found that prevent me from focussing, engaging, and helping my pair.
“Hangry,” a portmanteau of “hungry” and “angry,” widely refers to the people being irritable because they are hungry. Being hungry – or hangry – can hamper your ability to focus and be a constant thorn in your side. Ensuring that you and your pair are well fed (and thirst quenched) will allow you to be more productive, so if you need to take a quick break and get a snack or a drink – do it early and often to stay refreshed, focused, and productive.
Not taking breaks
Pairing can be exhausting after long periods of time. It can be difficult to stay focused, so it is important to give yourself breaks to recharge. At minimum take two 15-20 minute breaks a day. Ideally, these can be ‘natural’ breaks – that is, breaks around downtime where work naturally slows down. For example before or after a meeting, or when you are waiting for your CI/CD build to wrap up. This will not always be possible and it’s more important to take a break than to wait for the perfect opportunity. During your breaks, I would recommend getting up and doing something physical if possible. Playing ping-pong, going for a walk, stretching, or doing a 3-minute plank. Give your mind, and your eyes, a break.
As we will touch on later, the heart of pairing is the interactions between pairs. Natural human reactions to silence are to assume the worst, get frustrated, or be silent as well. Pairing does not need to be a 24/7 chatter session: there are times when silence is appropriate. When the course is set, the problem is known and you are just executing. But if a member of the pair, or both people, are consistently silent I would be concerned that one pair member may be disengaging and not contributing. Pairing is the melding of two minds and if one mind is not sharing you are receiving only partial benefits. When pairing, it is important to make a concerted effort to think out loud and include your pair in your train of thought – even if it is not fully developed. Pairing is a skill that you improve at, not an innate ability, and talking while thinking is a part you will grow in.
“Pairing is a skill, not an innate ability”
Responding to interruptions
A potentially controversial topic in pairing is how you handle interruptions: a random slack message, an email invite, a phone call, a support request, or someone walking up to you or your pair asking if you have a minute. If you want to disrupt pairing as much as possible, take every possible opportunity to leave your pair. If you absolutely must attend to the interruption, ensure you bring your pair with you and explain the situation to ensure context is shared. As much as possible, when pairing I recommend turning off all non-urgent notifications. During your breaks you can check these. Note here: there is an attitude in many companies and teams to want to respond to everything instantly, which is a good reflex to provide great service but can interrupt your ability to deliver great software. I would recommend working as a team to find a system that works for you, but that is beyond the scope of this article. Rarely, if ever, are things so important that they absolutely cannot wait.
Not being present
Pairing relies on two people respecting each other, otherwise, you cannot work effectively together. This means that if one person is driving you should not be multitasking, checking slack or on your phone playing a game. It also means that you should be in a physically attentive position to give as many positive non-verbal cues to your pair. This is especially true when remote pairing that you should (as much as possible) have your camera on, in a good position so your pair can gauge non-verbal cues. Like when you may need a break, are confused, need to go faster/slower, or rotate positions. I would highly recommend talking to your pair if you notice they are distracted/disengaged or not having their camera on and see how you can pair effectively. Always ensure that you have your camera and audio on. If you’re working from home, and you’ve got kids running around in the background, use these situations to further enhance dialogue and relationship building with your pair. We all live normal lives outside of work, so there are many ice-breaking topics that sometimes just need a push in the right direction.
There are a lot of opinions around pairing (the irony that I add but one more opinion is not lost on me), and I think it’s important to know where it is important to be disciplined and dogmatic; and the areas where pragmatism is appropriate. The goal of pairing is to produce effective software efficiently. So anything that helps us deliver better software in less time with fewer bugs should be prioritized.
Accepting meetings in the middle of the day
Pairing relies on extended periods of focus, so having meetings that prevent those extended times will inhibit pairing’s effectiveness. This is doubly true for same-day meetings. While I understand this is not always possible, I would strongly recommend creating a meeting culture in your team/org that all (as many as feasible) meetings should be immediately after standup, around lunch, or – for retro – towards the end of the day; and that all meetings are scheduled at least 1 day ahead of time. When you attend a meeting, so should your pair.
“You have to pair all day or not at all”
I have seen attitudes where pairing is all-or-nothing and while I do see value in that, I believe that pairing can be effective even if not done in full-day sections. Below are some of my opinions on scenarios where partial pairing may be appropriate:
When onboarding a new engineer – especially one who has only limited prior exposure to pairing – it may be more effective to pair for 5-7 hours a day and allow them some time for independent study, reflection, and exploration that may not be feasible for pairing. Early on with new engineers is the best time to start the necessary relationship building that will be needed long term for the engagement.
Research/chore heavy team
If you are on a team that has a large chore backlog, is pursuing many early-stage PoCs, or has a lot of research that needs to be done, then I think 3-6 hours of pairing complemented by some solo research/chore time can be good. This is especially helpful if team members are in different time zones/schedules as it allows the team to work together during core hours and maintain their preferred schedule.
There are of course other times when full-time pairing may not be effective. In those cases, you can suggest an experiment for perhaps a 75%/25% split where you pair for 6 hours a day and solo for two hours and set up the right parameters for those solo hours (for example no story work and any commits should be reviewed with your pair the next morning). It’s important not to be completing user-stories as you solo as you will miss out on the key advantages of pairing.
This final section talks about the ways that pairing can be sabotaged unintentionally through interpersonal interactions and a few suggestions. Pairing is very personal. You are sharing your space, your time, and perhaps even your keyboard, mouse, and computer screen. In a way, you are sharing yourself. It’s important to be personal, and personable so pairing can be effective. Below are a few attitudes I have seen that can create friction between pairs and inhibit effective pairing.
Assuming Pairing is innate and not a skill
A key pillar of pairing is the unique whole (of pairing) is greater than the sum of the parts. As mentioned above, pairing is a skill and you can get better at it. This is true for a variety of reasons but largely relies on each person bringing the unique parts themselves to pairing. As you pair more and more you will feel more comfortable in each of the two roles – navigator and driver. Learning how to perform these well, and what is effective and ineffective for you and your pair. Knowing when to ask for help and when to keep diving in.
“Pairing [produces] the unique whole [which] is greater than the sum of its parts”
Not treating your pair as a partner
This is a simple one, but you and your pair are partners. Even if one of you has 20+ years of experience and the other is a high-school senior there are always different and interesting perspectives to take when pairing and we should be open to that. Less experienced people may ask “dumb” questions but often these help us think deeper about the matter and uncover assumptions we did not know we had. Any time we start thinking about being “better” than our pair or that pairing is not worth our time it’s worth examining ourselves and asking if we see our pair as a partner. Furthermore, as you pair more you will understand the unique background (technical and not) that you bring and how it adds to your team. The same is true for each other team member. If you want, you can make it a game to find the distinct contributions and partnerships you can have with each pair to best collaborate.
Navigator backseat driving
There are few things more annoying when driving than a backseat driver. Someone who thinks they know better than you when to turn or merge lanes. One of the reasons this is annoying is because it can imply that you did not know what to do, and it can break your concentration – making you feel self-conscious. The same is true in pairing, if you find yourself as a “navigator” consisting primarily of pointing out small typos and variable names then you aren’t navigating effectively. You are disrupting your partner and preventing both of you from entering Deep work. Instead, the navigator should be focussing on the next high-level task: integration tests, the next phase of implementation, etc. Sometimes the detailed suggestion can be helpful especially if they are stuck. More often than not it’s better to focus on the big picture and let them figure out the details. Anything that undermines your pair’s confidence, and makes them feel self-conscious instead of a state of flow should be avoided.
Not swapping roles
If you find yourself backseat navigating it may be time to ask your partner to rotate and start driving. I know when I am pairing and not driving for a few hours I can get antsy and want to dive in. That’s ok! How often you rotate roles will depend on your team and temperaments but at the minimum I would recommend rotating at least once a day. At minimum! It could be swapping every few minutes (as in Ping Pong pairing, read more about ping pong styles here ). Swapping roles gives your brain a fresh way to look at the problem and let you interact with your pairs role more closely and ensure you are bringing out the best of both of you.
Not swapping pairs
Some of the benefits of pairing involve the sharing of ideas and pulling in different strands from each person’s background as well as the unique perspective they may bring to new problems. These advantages are much diluted if you are not regularly swapping pairs. Ideally, you would be swapping pairs every single day, but the minimum should be twice a week. If you don’t, there is a risk that a pair may go rogue and refactor the whole system without the other team members being aware. This results in a system that is harder to maintain, less context shared and higher overall levels of technical debt and code-ownership throughout the team – this may seem like a crazy situation, but I have seen this exact situation happen… twice). Moreover, you may start to see mini-siloes emerge as the same one or two people start to “hoard” stories about certain parts of the code and you become dependent on them for those features/maintenance instead of everyone having full code ownership. In short – swap your pairs.
Not sharing feedback
The Agile methodology, and especially XP, relies on feedback as a key mechanism for forward motion. This is especially true in the skills that XP relies on and nowhere is that more true than in pairing. Without timely feedback, a team’s pairing, and therefore their productive output and morale, can plummet in a matter of weeks. I would follow the advice of the New York subway, “If you see something, say something”. Giving and receiving feedback can be hard, it can feel uncomfortable and stretching but it is so valuable, both to the organization, the person receiving it, and yourself. “Your growth as a conscious being is measured by the number of uncomfortable conversations you are willing to have” (Kevin Kelly) so if you see something, consider saying something.
Feedback is so important it deserves a longer section. Feedback is critical as is the ability and willingness to speak up. If you join a new team and you see that they are not pairing well then you should definitely speak up and say something. In the short term, there may be a shock but it will pay massive dividends. Pairing is a skill, and like any skill, if you develop bad habits unless someone calls them out you will likely continue in those bad habits (and worse even teach them to others). Pairing and XP is a team sport, in the same way, we would talk to our fellow soccer/football/basketball players about their shooting form we should do the same for our pairing form. Sometimes a team will need a reset. As happened to a team I had been around for about 18 months, a senior anchor joined the team and within a week told us we were pairing badly. It was hard to swallow at first, but we reflected and agreed. We reset, realigned, and “re-introduced” ourselves and the results were startling and apparent. The team was laughing more, cameras were on and we were delivering better results. Giving feedback and calling out bad practices actually works.
So how can you share feedback? If your team has retros those are a great opportunity to share broad feedback and I think more people should take advantage of them. For more personal & consistent pairing feedback, I would recommend doing “plus deltas” at least once a week when pairing (and ideally every day). “Plus deltas” is a very simple feedback exercise you can do at the end of the day in less than 10 minutes. You ask two simple questions: what did we do well (plusses) and what do we want to change/improve (deltas). Write these as an email to each other, and be accountable. If you do this regularly (and again even giving and receiving feedback is a skill you’ll improve at) your pairing will get better.
“Your growth as a conscious being is measured by the number of uncomfortable conversations you are willing to have.”
– Kevin Kelly
Not letting the other person try ideas
When you and your pair are facing a problem and you both have an idea (or two) about which way to go it can be tempting to forcibly push for your idea. Perhaps their solution is wrong/dumb (you’re 100% sure). The best pair programmers know when to say “let’s try your idea first”. Even if it’s only for 30 or so minutes and helps them realize why it won’t work. There is something so valuable not just being told something won’t work, but reaching that dead-end yourself. And sometimes, it may just work and you’ll be amazed. So, sometimes, let the other person try their idea first, you can go second and then make an informed decision – together.
Pairing is an interpersonal skill that requires two people to be committed to working together to create a whole that is greater than the sum of its parts. It can be tiring, so take breaks. It can be hard, so talk about ways to make it easier. It can be fun, so take advantage! I truly believe that with effective pairing you will create better software, with fewer bugs, and more uptime in less total time.
So there you have it: some 14 odd “anti-patterns” of pairing that I have pulled out from almost five years of pairing. I hope this has helped you as you think about your pairing and given you some inspiration about how to make it better. I’m sure this list is not exhaustive and I would love to hear your thoughts: what did I miss? What did I get wrong? Please let me know in the comments or at firstname.lastname@example.org!
 Deep Work by Cal Newport: https://www.calnewport.com/books/deep-work/
 Different pairing styles: https://tanzu.vmware.com/content/blog/what-s-the-best-way-to-pair
 Good Life advice referenced in Feedback section https://kk.org/thetechnium/103-bits-of-advice-i-wish-i-had-known/
 Pair programming definition I enjoy https://www.techtarget.com/searchsoftwarequality/definition/Pair-programming
 Martin Fowler on Pair Programming https://martinfowler.com/articles/on-pair-programming.html#ThingsToAvoid