Chapter 3. Being a Better Partner – Practical Pair Programming

Chapter 3. Being a Better Partner

My grandfather once told me, “Marriage is not about finding the right person but rather about becoming the right person.” In other words, a lot of a partnership’s success is within your control.

Pair programming may not have the permanency and legal implications that marriage does, but it’s a pretty intimate thing to let someone else see exactly how you work. Complicating the arrangement is the fact that you might have little choice in who you’re partnered with. If you don’t trust and respect them, it can be a real struggle. “I only like pairing when my partner is a pleasure to work with,” software engineer Ryan Kulla tweeted. “So I try to be too” (http://bkaprt.com/ppp/03-01/).

Working with difficult people is a fact of life, and the earlier you develop the skills to receive their energy and turn it into something positive, the quicker you’ll succeed in your objectives and advance in your career. Don’t write someone off just because you’re having difficulty with them in the moment—people and circumstances can change!

Let’s dive into some good pairing habits you can develop that add value to the pairing relationship and leave everyone feeling better for having engaged in it.

Think Out Loud

If you were to listen in on a pair, you’d often hear such things as:

  • “What do you think? Is this right?”
  • “Do you mind if I drive?”
  • “Let’s see if that worked.”
  • “I’m going to grab the mouse.”
  • “Can I look at something?”
  • “I’m thinking the problem is… What do you think?”
  • Go ahead.”
  • “Sounds like we have different opinions. Let’s try yours first.”

This level of chatter is in fact a fundamental habit of pairing: There should be a dialogue running almost continuously. The driver (the one controlling the keyboard at the moment) is constantly thinking out loud in a practice called “reflective articulation,” which helps the navigator (the one not typing) understand what they’re doing and keep up with what’s going on (http://bkaprt.com/ppp/03-02/, PDF). The navigator should be acknowledging the driver’s narrative, filling in the gaps, questioning their choices, noting potential problems, helping remember what that thing over there was called, and helping direct where to go next.

It’s hard to remember to think aloud when we’ve spent so much of our lives in school and solitary work environments keeping our thoughts inside our heads, but with practice, it can become second nature. Remember: Silence is selfish. Go ahead and share what you’re thinking, whether you’re the driver or the navigator. If your partner goes silent while continuing to work, “Hey, catch me up with what you’re thinking” is a friendly prompt to come back to the pair and contribute to the shared experience.

It won’t take long to realize that you and your partner may have completely different styles of thinking through a problem. Because reflective articulation is so important, asking the right questions when you’re not following (or agreeing with) your partner is critical.

I’ve learned from business leaders and psychotherapists how powerful curious, genuine inquisitiveness can be. Often the best solution isn’t one either I or my partner thought of initially, but rather a hybrid we developed by piggybacking off each other’s ideas and gently guiding each other along with a series of thoughtful questions.

Good questions are open-ended, asked with genuine curiosity, and non-judgmental.

  • Inquire about their reasoning. If you ask, “Why did you make that choice?” you acknowledge that there were multiple approaches and they selected one, whether they realize it or not. You get to hear what they rejected and why. If they didn’t consider anything else, hopefully they’ll ask you what other ways you see.
  • Consider alternatives.How else might we accomplish the same thing?” invites you to come up with alternate solutions. “Is there another name that would be more semantic?” gently questions whether their choice conveys the right meaning (and we know naming things is hard!). “Is there something we could abstract from this?” invites reflection on function/class size and the single responsibility principle.
  • Be open to experiments. Maybe the alternative your partner just suggested sounds outlandish to you. Don’t waste too much time debating hypothetical principles. Save your work and try the alternative on for size. Maybe you’ll like it once you see it, and there’s little in the computer world that can’t be undone or reverted.
  • Ask whether the juice is worth the squeeze. An important job when you’re the navigator is to provide a “subliminal process check” and speak up when you think you’re working too long, trying too hard, or going too far on a task. Try questions like, “Is this something we should spend more energy on, or is it good enough? Is there something else could we be doing that’s more valuable?” Weighing the value of what you’re working on versus the effort required should always be in the back of your mind.

It’s important to employ non-confrontational questions to keep yourselves in a critical-thinking space without putting each other in a defensive mode. Always keep in mind the overarching objective and make it explicit when necessary: you’re working together to discover the best solution.

Check Your Ego

When developers fear losing their identity, their personal style, and their sense of control, it presents a real challenge to effective pairing. I’ve heard many stories of developers intentionally obfuscating their code or adopting an extreme personal style to make themselves more indispensable, perhaps reasoning that if they don’t rule their corner of the codebase and defend it from all intruders, they can be replaced easily. Others might go to the other extreme and have a crisis of confidence, thinking they don’t have anything to contribute. These are both examples of unmanaged ego, and it’s probably the number one threat to successful pair programming.

Pair programming is a practice that helps moderate ego, because we’re all simultaneously teachers and students. Learning from a colleague means finding the balance between questioning their assumptions while remaining open to having your own assumptions questioned in turn.

Looking at a language, framework, problem domain, or codebase through the eyes of a newbie can be a real gift; you drop your expectations and preconceived ideas and see things with an open mind, curiosity, and fascination—a state of mind called “beginner’s mind” in Buddhist practice. You notice what’s going on, try to see the details, and don’t take anything for granted. A beginner exposes where the code doesn’t adhere to the Principle of Least Astonishment (POLA), which is when a piece of code does exactly what you’d expect it to do from reading over it.

If you suffer from too little confidence, pairing can be an opportunity to see inside someone else’s work and realize that they really aren’t any smarter, faster, or better than you. “I find that pairing regularly is great for my confidence, getting to see everyone else typo and Google stuff too,” programmer Danielle Sucher tweeted (http://bkaprt.com/ppp/03-03/).

Wherever you are on the software engineering growth curve, you’re probably the best person to teach the knowledge you recently acquired to the folks just behind you. It’s a gift for you as well, because by articulating the thinking, circumstances, or history behind why things are done a certain way, you’ll get an even better grasp yourself on the principles you’ve already learned.

Growing as a person who can pair confidently with anyone requires introspection, acceptance, and commitment to the practice when it would be easier to quit. In the words of IBM CEO Ginni Rometty: “Growth and comfort don’t coexist” (http://bkaprt.com/ppp/03-04/).

Of course, the only person over whom you truly have control is yourself; no matter how much humility and non-defensiveness you model, you may still find yourself paired with someone whose ego becomes a real problem. This brings us to another important practice in pairing: getting comfortable with giving and receiving feedback.

Give and Receive Feedback

Each member of the team needs to be open to giving and receiving critical feedback. Being a good pairing partner means staying engaged, wrestling with interpersonal challenges, and not checking out and walking away when you experience adversity. Yes, it would be easier to hide behind your own screen and ice out a difficult collaborator, but you’re just putting off a larger conflict.

In my opinion, honesty and kind-but-fair micro-confrontations are better than repressing resentment. I believe (or at least operate as if) everyone is trying their best and would want to improve if given the right information. I’ve found success with a few different approaches:

  • Soften the criticism by asking permission first. “Can I offer some feedback?” you might ask. “Can I bring up something I noticed?”
  • Frame it as an observation. “So I noticed we’ve been leaving a lot of comments about what the code does. I wonder, is that something we should be doing?” (Even if you’re sure it isn’t, make sure you ask sincerely.)
  • Emphasize what you would improve, not what went wrong. “Next time, I would like to spend more time driving, because I need to get a better feel for where things are in the codebase.” Or perhaps, “Next time we should try ping pong pairing, so we each have equal time driving. Would you be open to that?”
  • After a pairing session, conduct a nano-retro to quickly evaluate it and make improvements. On the count of three, each person scores the session on their fingers from zero to five. Take turns sharing what improvements would have made you give it a five and record the improvement ideas for the next time you pair together.

When you’re on the receiving end of critical feedback, it can be hard to take! You may feel misunderstood or even attacked. But try to see it as a gift, because new information is the only way to grow and we all have things we can learn about ourselves and our work. Don’t explain or defend; just offer a simple “Thanks for the feedback” so the person offering it feels heard. Review the feedback later and decide what action you want to take.

When you implement a suggestion and find it successful, it’s good to share it with the team (if not too personal) so others can benefit from your learnings. As a group, talk about what’s going well with pairing, what’s not working, and what you’d like to change. Perhaps you need a better hardware setup, a subscription to a better remote pairing tool, an environment with fewer distractions, a less library-like atmosphere, longer or shorter sessions, or different parameters around rotation.

Becoming a better pairing partner is all about curiosity, experimentation, and reflection—thinking about how things could be better and giving it a shot. Not every idea is a good one, but it costs very little to give something a try. Clear, direct communication will establish trust, which is ultimately what makes our pairing highly efficient and our work product the best it can be.