The Elements of Highly Effective Pair Programming

February 6, 2019 Steven Solomon

Do you feel like you aren’t getting value from pair programming? Is it difficult to know what your next move is? Does one person zone out while the other works as if they were alone? If you answered yes to any of these questions, then I can help.

In this article I will tell you how to make your pairing session more effective by showing you ways to set expectations, common patterns of pair programming, and how to get your session unstuck.

Setting Expectations

Before you write a single line of code together, it is important to set clear goals for the pairing session. Without goals, it will be easy to get off track and fall prey to frustration.

It’s imperative to ask both your pair and yourself the question: “Why do we want to pair together?” Is it to share knowledge? Is it to teach a new refactoring technique? Is it simply to collaborate? Great, write that down and say it out loud.

From the moment you have set shared goals, both you and your pair will be responsible for staying on track.

Distractions

Deciding on what you don’t want to accomplish is also important. Take the time to define what you both consider a distraction. Your shared anti-goal can be used as a heuristic to make sure you both stay on track.

Start out by listing the meetings or commitments you will have during the day. This visibility will help you choose the right moment to take breaks.

Just like goals, it is both team members’ responsibility to help avoid distractions. During the session, when potential rabbit holes come up, the person not typing should write them down. This will allow you both to circle back at a later time.

Some scenarios may crop up that are not distractions. These are genuinely more important than the current task, for example, a production outage. Do not treat these as if they are distractions.

Pairing Patterns

There are a few different patterns of pair programming that you might find helpful. Patterns can help work feel more like a game—allowing you to concentrate better. Each pattern is described below along with a list of its benefits and risks.

Driver/Navigator Pairing

Driver/navigator is a great technique for sharing information between people. It divides a pair into two distinct roles: a driver, someone who types; and a navigator, someone who decides where to go. You and your pair should switch roles about every ten minutes.

When navigating, it is important to speak in the highest level of abstraction understandable for your pair. For example, don’t say “Click this button, then that one. Next type this —” Instead say “Rename the function to doThing.” If your pair doesn’t know what the steps are, then walk them through it. Afterwards restate the abstract name you gave the step.

Benefits

  • Having to describe what to do next forces the navigator to be able to explain the steps.

  • Typing out commands will increase retention.

  • Build up shared pairing language.

Risks

  • This technique doesn’t lend itself to exploratory work (where it isn’t clear what to do next).

Ping-Pong Pairing

Naming is hard, and this style of pairing has nothing to do with actual ping-pong. Instead, you and your pair rapidly bounce between typing as you practice Test-Driven Development (TDD) code. Unlike the driver/navigator pattern, when typing as part of a ping-pong pair you get to decide what the next step is.

An example is: one person writes a failing test, then the other makes it pass and writes the next test, and repeat.

Benefits

  • Allows pair to focus on delivery.

  • Fast feedback loops between test failures.

  • Having to make the test pass validates understanding of the problem.

Risks

  • This style works best when both people have some experience with TDD .

  • Not a good strategy for exploratory work.

  • Requires pair to have short time between failing tests, yielding smaller tests.

Unstructured

Sometimes, you don’t need a structure; you and your coworker can simply collaborate. For this pattern, both people simply talk about what they want to accomplish and then do it.

When one person gets stuck, switch who is typing. Try the phrase, “May I try something quick?” when jumping in. Remember that it is important not to try to grab control while your pair is mid-thought.

Benefits

  • Unrestrictive, you can collaborate as you wish.

  • Great for exploratory work.

Risks

  • Doesn’t lend itself to sharing knowledge as readily as you can just try something without explaining it.

  • If both people aren’t assertive, then this could devolve into one person typing for a large amount of time.

How Do You Get Unstuck?

Once you try pairing for a time you will begin to notice when you get stuck—the progress feels harder to achieve, you can’t think of what to do, or you have a disagreement. Here are some strategies to navigate those problems:

Pulling Information From Your Pair

There are moments during pairing when your driving partner seems to be flailing, and you don’t understand what they are doing. They write a test that is cryptic and it fails, and they can’t make it pass. This is a great moment to invite them to think out loud.

Thinking out loud can expose a lot of insight into why your partner was getting stuck. It also shows you their thinking patterns, allowing you to better explain your ideas. Asking your partner to think out loud will create an opportunity for you to listen, and help them get to where they want to go.

In this situation, the best thing you can do is attempt to figure out where they want to go by asking questions until you understand. Don’t try to grab control or drastically switch direction, instead, help them reach a natural conclusion to their thoughts. Then if it is appropriate, invite them to try another strategy.

Not Enough Options

You might come to a point where you both don’t know which direction to take. You might feel like there is only one option. It might be tempting to think “It has to be x.” If you can’t see a few options, then try out Jerry Weinberg’s Rule of Three.

The Rule of Three says that “one option is a trap, two options are a dilemma, but three breaks logjam thinking to enable creativity” By forcing yourselves to see at least three options — even though some of them seem unappealing — you will discover that you can think of many more options.

Strong Opinions

There will be times when you and your pair have strong conflicting opinions. In these moments it is important to recenter on the goal of your pairing session. This can help you negotiate with your emotions, and make a compromise. If negotiating with your emotions didn’t help, take a break. Maybe you both need time to cool off.

Upon your return, if there is still disagreement about where to go next, invite a timeboxed spike for each option. This will allow you both to see what the code can actually look like, rather than talking about boxes and lines. If you both agree to implement both solutions, you have to actually implement both. It is not okay to implement the solution you want, and then start arguing that the task is finished. This lacks respect for your pair.

If the spikes didn’t get you unstuck, ask yourselves, “Why do I feel so strongly about this implementation?” Once you understand how you feel, and why, then invite your pair to share their thoughts and feelings. Use the Socratic method to get to a state of shared understanding. Once you believe that you fully understand, attempt to recite their solution. Do this until they feel that you fully understand them. 

Next share your idea, invite them to ask questions, and recite it in their own words. Then, share what you both see as tradeoffs of your own solution—not theirs.

Letting this disagreement go on too long can have a negative impact on the team. If you can’t make a shared decision, invite another team member —or lead—to be the tie-breaker. Take the time beforehand to agree that whatever the tie-breaker votes for will be the direction. 

Agile is about working collaboratively with people, and that you should be prepared to compromise.

Too Many Options

If you have too many options, try to prioritize with one of the  techniques below:

  • Dot voting — List out all of the possible options. Everyone votes with their dots (each person gets two dots). The group then reads through the options starting with the item with the most dots to least dots. If there is a tie, use “Try them all”

  • Try them all — Attempt every option, one at a time with a time box. After the timebox expires, write down the tradeoffs you noticed.

  • Use a 2x2 — Draw a two-axis grid with easiest on the x-axis and how well it solves the problem on the y-axis. The easiest and most beneficial strategy should be in the upper right corner. Place your options on the 2x2. Try options from upper right (easiest and most beneficial) to upper left (hardest and most beneficial), until you find a solution that works.

Making Room for Humanness

You are both humans, that means that extending periods of focus can be draining — it doesn’t matter if that time is positive or not. Make sure to take regular breaks.

Though you may feel pressure to stay seated at your desk, give yourself permission to take a break. If you are tired or stuck, a 10-minute break can drastically relieve tension and even give your brain time to process what it has learned. Before you leave your desk, decide where you will start when you come back and leave a failing test if possible.

Once you come back, you will be surprised how easily things begin to flow — almost as if the stones have been removed from your path.

Conclusion

So we’ve discussed some techniques to improve your pair programming session. We talked about setting expectations, structuring a pair programming session, and a few ways to get unstuck.

Valuing each other as people is an essential part of pair programming. People are messy, have emotions, bad past experiences and quirky personalities.

Taking the time to get to know your pair, and sharing experiences can build trust which goes a long way towards building a healthy team.

While you pair with someone, make sure to create room for their humanness, and they will respond in kind for you.


Follow the author on Medium at @ssolomon

 

About the Author

Steven Solomon

Steven Solomon is a Pivotal Labs Senior Software Engineer based in New York.

More Content by Steven Solomon
Previous
Root Cause of an Application Outage on Kubernetes, and How We Fixed It
Root Cause of an Application Outage on Kubernetes, and How We Fixed It

A story of an outage one application took while running on Kubernetes, how we determined the root cause, an...

Next
How Two Operators are Continuously Patching Pivotal Cloud Foundry
How Two Operators are Continuously Patching Pivotal Cloud Foundry

Learn how two Pivotal customers, Cerner and Wells Fargo, are staying secure.