How To: Get the Most Out of Pair Programming

Table of Contents

• Why Should I Pair?
• Stick to Your Roles
• Open Communication
• Write, Draw, Model

Whether you are at the very beginning of your career in programming, having been coding for decades, or anywhere in between, it’s likely you would find some benefit from pair programming. Humans are naturally social and collaborative creatures, and pair programming looks to take those attributes of humanity and use it to enhance not only our code, but also our knowledge.

Why Should I Pair?

Perhaps you’re wondering why you would want to invite another person to join you at your keyboard. Maybe you don’t like the idea of letting someone else tell you what to do. Maybe you prefer having time to work through problems alone. Maybe it’s just a simple case of feeling awkward letting someone else see you struggle with something. While all of these are completely valid feelings, the benefits gained from collaboration are worth dealing with the discomfort that can be caused by working with others.

While you may be an experienced programmer, or even an expert in your particular specialty, there are a lot of arguments in favor of pairing. Having two people work on a piece of code together allows two sets of eyes to catch bugs that might be introduced, it forces a programmer to question their preferred style of coding, it allows each person to maintain a deeper focus on their task, and plenty more. In this piece I’ll be covering some common mistakes to avoid when pairing, and what benefits you can expect to gain by teaming up.

Stick to Your Roles

I find that one of the biggest missteps people make when pair programming is not properly understanding or maintaining their individual roles in the pair. There are a few things that pair programming is not. It is not having two people sit near each other at two computers with two keyboards. It is not one person coding while another person watches. Each person in the pair has a very specific role, and keeping to that role will maximize the benefit gained by pairing.

The person at the keyboard during your pairing session is called the driver. The driver is responsible for not only typing out the code, but also maintaining correct syntax and focusing on the very specific task at hand. In metacognition terms, the driver is engaging in discrete and technical thought. The driver should be paying attention to the small details; she should be focused on the current method or chunk of code being written and nothing else.

The person without a keyboard is the navigator, and their role is generally less well comprehended. The navigator is not a passive observer, but is instead the big picture thinker. She should be making sure the project is heading in the right direction, keeping the driver on task, and offering suggestions for next steps and strategies. As opposed to the concrete thinking of the driver, the navigator is engaging in abstraction and longer term planning. This is meant to free the navigator up to come up with ideas that the driver might not have while focusing on the nitty gritty syntactical work.

The key reason for maintaining these roles is that it allows each person to fully engage in one mode of thinking, reducing the negative effects of multitasking. Each member of the pair can fully focus on one aspect of the project, rather than switching their attention back and forth.

In one particular experience I had, although we had the intention to pair program, due to our lack of understanding of how pairing worked my partner and I ended up working on two separate computers next to each other. This meant that we were using two completely different solutions to the problem at hand rather than collaborating on one piece of code.

This is why I recommend only having one keyboard during a pairing session, although some people prefer to keep two keyboards connected so they can more easily switch roles when the time comes. In that case, I would suggest turning the navigator’s keyboard so it’s facing backwards so they aren’t tempted to jump in and drive. I also find it’s more convenient to pair with two monitors, so both people don’t need to be cramped into one small space. This not only prevents strain on the neck or eyes, but also can relieve interpersonal tensions by giving each individual their own space.

Open Communication

Another vital factor in successful pair programming is maintaining an open and honest dialogue. If you have serious concerns about the direction in which things are heading, speak up and address them. If you don’t understand what your partner is doing or get lost, stop and ask questions. Pair programming is designed to increase efficiency but it is also an excellent tool for learning and sharing knowledge. Allowing any embarrassment about not knowing something to get in the way of your learning is a detriment to both you and your partner.

This doesn’t mean that you should voice every disagreement that you have however. The expression “Tim Toady” (TIMTOWTDI) has been used to mean “there is more than one way to do it”, and this is true in many programming languages. While you may prefer a different method or style than your partner, keep in mind that that doesn’t necessarily mean that your way is “right”, or that your partner’s is “wrong”. You should be respectful of each other when pairing, and remember that refactoring can always be taken care of after you have a working piece of code.

Write, Draw, Model

There may come a point while pairing when your team becomes stuck. You just can’t quite figure out how to implement a method or how an algorithm should be working. This will often lead to frustration and trying a lot of code hoping something eventually works. Something I would recommend trying instead is to model your code in a variety of different ways. Perhaps the most common tactic is to whiteboard a solution in pseudo-code, which allows you to focus on the flow of your code and ignore the syntax temporarily. If we want to take this strategy a step further, we can engage in other models of thinking and learning that can allow epiphanies that might not occur when writing.

While writing or speaking are the most effective ways for some people to solve a problem, others get the most benefit from visual representations. The visual learners may be able to make more sense of a problem if they sketch or diagram potential solutions. Kinesthetic learners might get more benefit by gesturing, or even acting out a problem physically. By applying a sense of 3D space to something it engages different parts of the brain and can lead to novel thoughts. While it may not be the most practical technique, some people even find it helpful to model solutions to difficult problems with blocks or other physical objects.

There have been several pairing situations I’ve been in where we found ourselves stuck on a particular piece of code, and no matter how we talked it out it just didn’t make sense to us. By diagramming our approach, or by writing out in words what we were trying to do, our logic errors became more apparent. Figure out what kinds of modeling work for you, and keep materials on hand when you’re pairing, whether it be a whiteboard, pen and paper, etc.

There are many styles and opinions out there when it comes to pair programming, and this is far from everything to know on the matter, but hopefully this provides you with a starting point to practice pairing for yourself. If you keep these tips in mind, I have no doubt that you will find it a much more satisfying and engaging experience.

You can reach Chris Cerami on Twitter if you have questions or feel like chatting about pairing, Rails, or anything else related.

Launch Academy incorporates pair programming in it’s 10-week intensive learn-to-code bootcamp.  Learn more about Launch Academy by visiting their School Page or the Launch Academy website!