People who don’t like to pair program have a number of reasons that I won’t get into in this post. One that I will get into that regularly comes up is the frustration they feel when pairing with someone junior to them - someone who knows comparatively little about a problem or how to solve it. They feel that explaining things slows them down and uses up energy that they could direct toward solving the problem itself.

I understand where they’re coming from. Explaining things to someone is hard and takes a lot of energy. It takes patience, especially when the person just doesn’t seem to get it. I feel that frustration. I think of all the work I have left to do, a list of work that really will never end, and I think if I could just move through that list faster everything would be better. I feel the exhaustion of looking for new ways to explain things, knowing the answer but not knowing how to communicate it in a way someone else can understand.

All programmers feel frustration. We feel frustration when we’re first learning and are faced with the task of figuring out endless error messages. We feel frustration when code doesn’t work the way we think it should, or the way we want it to. We feel frustration when our managers change the requirements on us yet again, and move the deadline up a week.

Frankly, I’m not sure the frustration ever ends. We may feel we have reprieves from it, but in my experience it’s just that another kind of frustration has taken over for the time being.

Highly collaborative environments accept frustration - in fact they may encourage it in the form of tough questions and lively debates. Frustration, as something that never really ends, can be dealt with in a group in interesting ways that I don’t think are available to individuals.

When you explain something to someone, you take on all the frustrations that go along with that. You also take on their frustration in a way - by taking some on yourself, you allow their original frustration to be replaced by a different one that involves them grasping what it is you want them to grasp. If they are struggling to reach a branch, you may struggle in bending that branch towards them, but in doing so allow them to reach what they want.

By pairing, you work differently. You stop thinking solely in terms of producing software, and start thinking in terms of the human interactions that produce software. You start thinking of how you can communicate your ideas rather than simply how to execute them. You allow for ideas to be expressed out loud, interpreted by someone else, and fed back to you.

I believe that this approach will lead to better health and longevity for programmers than an approach based primarily on problem-solving according to a schedule. Such approaches create frustration without effective ways of managing it, and that leads to burnout. I have seen this in myself, my friends, and in people sharing countless stories across the web.

The next time you pair with someone, consider this: they don’t know less than you do, they know differently than you do. Their understanding of the world extends in ways that yours doesn’t, and by communicating with them you will learn new ways of thinking and experiencing. You will see the sorts of problems people run into when they’re unfamiliar with a system. This applies whether it’s at a code level or using the running software system. You have made many assumptions - among them the idea that writing code quickly has more value than teaching someone and exploring problems together. Your assumptions prevent you from seeing systems in a certain way, and someone with different knowledge than you can provide valuable insight through new perspectives.

Answering questions forces you to hear your thinking out loud and clarify your thinking in a way that you can express to someone else. This skill is invaluable in terms of your career and life, so if you can build it just by explaining things you know to someone who knows differently, you can make a big impact over the long term.

Beyond that, working alongside someone else is a great way to help them succeed. Sometimes people are afraid of competition, but that is very short-term thinking. The more people that do well in an organization, the more the organization needs to make room to let the successful people shine. When you do eventually leave a company, you are most likely to get your next job via someone you’ve worked with before. You’re also the least likely to get your next job via someone you’ve worked with before. As a friend of mine says, “You meet the same people coming up as you do coming down.” By working with someone to help them learn, not only will you build a connection with someone you value, you also invest in people that down the road are likely to be valued connections in your career and life.

For me, the main reason to pair is that I just like working with people! Things come up during the day that I find amusing, and I like to crack jokes. That works great if I can make a wisecrack in a second and keep going, but if I’m working alone and have to tap someone on the shoulder and interrupt them…well that’s too much pressure, and I’m just not going to do it. I also run into problems where I get stuck, and I really benefit from having someone else’s eyes and brain working on the problem. Whether they know the answer, or we figure it out together, I’m always in a state where I’m learning and rarely in a state where I’m stuck. If you can practice being in a state of learning rather than being stuck, and do that for a long time, you will be very effective as a programmer. Pair programming is a great way to be in a learning state, and that goes for both people.

The next time you pair, no matter how different your understanding is from another person’s ask yourself: “What can we do together, right now, and what can we learn from it?”