Todd Sedano

Software Engineering, Improv, Craft of Software Development

Considerate Pair Programming - Part 2

Strategies for Success in Pair Programming

In my software development practice, I rely on several techniques for increasing the probability of success with a pairing relationship.

This article contains a toolbox of techniques. Feel free to pick a few to try out and then revisit the list in a few weeks.

Become invested in your pair’s success is the major take-away. When I am taking care of myself and looking out for my pair, an incredible friendship can form. Consider “what are my pairs strengths? And how do they map to my weaknesses?” and vice-versa. Have I always been invested in my pair’s success? No. My pairs probably have stories on how I could have improved in my pairing. Shifting from “what is in it for me” to “what is in it for us” enables new pairing dynamics.

This is a three part series covering strategies, techniques, and tips for Considerate Pair Programming.

Part One covers Why We Pair and Setting up the Work Environment for success.

Part Two covers Strategies for Success including

  • welcoming interactions at different parts of the day,

  • reflecting on the pair programming experience, and

  • reframing interactions for growing collaboration.

Part Three covers what to do When Things Go Weird

Remote pairing presents its own set of challenges. See my remote pairing blog post for techniques to improve remote pairing effectiveness.

Remember that our overarching goal is to to create a welcoming and safe environment for both pairs.

Welcoming Interactions at Different Parts of the Day

Introduction and First Impressions

“I am looking forward to pairing with you.”

What: Start your day by making your pair feel welcomed. If you are excited to pair, then mention the reasons. People can spot when others are insincere, so only say it if you mean it.

Why: We want our pair to feel welcomed.

When: I use this periodically so that it does not seem formulaic. When pairing with a stranger outside of work, I will include a handshake and introduce myself. “Hi, I’m Todd, and I’m looking forward to pairing with you…”

“What is your ideal pairing day?”

What: I ask my pair to tell me about their ideal pairing day. Some people have never considered the question and are surprised by it. Some need clarification about what I am asking. I will respond with “After a day of pairing, when you leave work energized, what caused you to be energizing?” or “What enables you to have a successful day of pair programming? What do you need from me?”

Why: If you both have different goals for the day, talking it out may help you understand your pair’s motivations.

When: I do this when I pair with a person for the first time.

The common responses are

  1. I love it when we deliver lots of stories (these tended to come from client developers);

  2. I love it when we solve a hard problem;

  3. I love it when my pair and I are on the same page working harmoniously.

Starting a Day

“How is it going?” or “What did you do over the weekend?”

What: Take a moment to find out how your partner is doing.

Why: When starting a day with my pair, it is super tempting to jump into the work immediately. We may be eager to start delivering value. I find that I need to stop myself and acknowledge our humanity. I enjoy just checking in with my partner. In American culture, “How is it going?” can be a throw-away greeting, so I look my pair in the eye and ask “How is it going?” in a way that communicates that I am honestly interested and curious about their wellbeing.

We are integrated people. Things that happen at home affect us at work and things that happen at work affect us at home. A harrowing adventure on a commute may affect us emotionally and may affect the dynamic between the pair.

“I am concerned about _____” / Addressing Concerns

What: Reveal any concerns that you have about the day. Discuss anything that might affect the pairing relationship. Your concerns could include the story, the work, or the pairing.

Why: Our feelings or anxiety may affect the pairing relationship. Discussing our feelings helps remove the energy around that feeling. See the section on Sensing Strong Feelings for more details.

Examples: Here are some examples from my experience:

  • “I am anxious about getting to the root cause of [this tricky technical issue],”

  • “I just had this difficult conversation outside of work and I can tell it’s affecting my mood,” or

  • “I am worried that this feature is taking too long to finish.”

Example: One of my pair types at 110 words per minute. Maximum my typing speed is 55 words per minute. I was intimidated by his typing speed. I felt like I was slowing us down. I felt that I had to type faster to be valuable. After a few pairing sessions, I acknowledging what I was feeling. Neither of us changed our behavior, but I was no longer intimidated. It became a non-issue. Acknowledging the situation allowed me to appreciate how he brought this fantastic skill to us as a pair.

One of my friends calls this “Name the Dragon.” Example: “Hey, I am feeling really edgy today because my whole day has been the opposite of what I’ve planned, from the moment I woke up… it’s not you, it’s me.”

Mid Afternoon Check In

“How is today going for you?” or “What could I be doing differently?

What: Check in with your partner about how things are going.

Why: Check-ins shorten the feedback loop. Hypothetically, say you are bothering your pair. How long will it take them to give you unsolicited feedback? A week? A month? Maybe never? It takes courage to provide unsolicited feedback. By broaching the topic and asking for feedback, you can reduce your feedback cycle.

When: About 2/3rds of the way through the workday. I prefer mid-day so that when I receive feedback, I have a chance to practice changing it immediately with that person. At Pivotal, we daily rotate with whom we pair. Asking at the end of the day requires me to wait several days before I have a chance to course correct. I set the alarm on my phone that goes off two hours before the end of the day.

Examples: I have received feedback on keyboard sharing, improvements to my development flow, and an ask for me to be more assertive. I even discovered that I chew gum too loudly.

If your pair might not be comfortable giving feedback, remind them how valuable the feedback is: “I value your feedback as it helps me grow. Please tell me one thing that I could be doing differently.” When hearing feedback, say “Thank you.” Do not argue about it as this appears defensive and your pair may not want to provide feedback again. It is fine to ask clarifying questions for the purpose of understanding their point of view.

If you find that you are not getting any constructive feedback, perhaps your pair is not comfortable giving feedback with you. Work with your manager. Your manager could ask for feedback on your behalf.

When I stop receiving constructive feedback, I ask “How was today less than exceptional?” or “What was less than extraordinary about today?” [reference] Experiencing an exceptional day is rare. The question sets the bar high, allowing your pair to voice any small improvement.

End of Day Wrap Up

Thank your pair for their contributions.

What: Mention particular accomplishments or strengths. Bring up unique ideas they offered.

Acknowledge if you accomplished more with your pair than you would have without them. Feel free to acknowledge the hard parts of the day. “Even though dealing with the build system was frustrating, I enjoyed pairing with you.”

Why: This gift ends your pair’s day on a high note. This action helps us practice gratitude. On a frustrating day, it is nice to acknowledge the pleasant parts.

When: I aim to do this about five to ten minutes before the end of the day so that I am not keeping my pair past the end of a workday. Some situations will preempt you from doing this action: the team may call a team huddle at the end of the day or you may be working on an energizing story and you both want to finish some part of the work. If I aim to do this every day, then I hope to achieve a good balance with the other interruptions.

The goal is to wrap things up and end the day on a positive note. I try to avoid rehashing or starting a day’s reflection; I practice at the Mid Afternoon Check-in instead. I want my pair to feel appreciated and for them to know that I look forward to our next session.

Reflecting on the Process / Conversations about the process

“How do we improve our development environment?”

What: Reflect about the development process.

Why: We want to have efficient development environments. Often an improvement in one development environment benefits the entire team. Discussing the development environment reveals concerns about the setup.

When: periodically

Example: How do we decide which editor to use? At Pivotal, the most common editors are Vim or one of the JetBrains products (IntelliJ, CLion, Gogland, RubyMine, PyCharm, etc.). What do we do when one pair prefers Vim and the other prefers a JetBrains editor? When an expert with a technology is pairing with someone learning the technology, I recommend using the editor that the novice knows best. The technology might be programming language (c, python, go) or a framework (spring, rails). This strategy allows the novice to focus on learning the technology and the expert has a chance to learn the less familiar development environment. At Pivotal, learning more Vim or more JetBrains makes each engineer a more well-rounded engineer.

“How do we reduce feedback time?”

What: Discuss the waste from long feedback cycles [reference]

Why: We want to have fast feedback loops. Unfortunately, there can be many technical obstacles that get in the way.

When: Discuss this topic when you are suffering from long feedback loops. If there is waiting time, we can use this opportunity to improve the situation and reduce waiting time in the future.

On my first Pivotal project, our test suite took about ten minutes to run. On our last week of the project, my pair and I decided to speed it up. In looking at the tests, we discovered that two of them took the majority of the time. One test grew the size of a cluster. One test created a cluster. One test destroyed a cluster. All of the other tests assumed that a cluster existed. By resequencing our test cases, we were able to speed up our tests significantly. We attempted to always leave a cluster up. By running all the quick tests first, if a test failed we would find it quickly. We then would then grow the cluster, destroy the cluster, and create a cluster thus leaving it in a state for the next test run. This resequencing decreased the test suite running time to a few minutes. We lamented that we had not made the change earlier. By removing waiting time, you enable your team to deliver faster.

Setting a learning goal

At the start of the day you can set a learning goal. “Let us work on understanding Test Driven Development today” or “Let us work on keyboard skills.” Try to frame it so that it is more collaborative. At the end of the day, each person provides feedback about the goal. Allowing your pair to know what kind of feedback ahead of time gives them a chance to observe you in action.

Looking for Gold

What: In the improv game called “That’s Brilliant!,” a team member offers a terrible, impractical solution for a problem. The group then uses the suggestion to look for divergent ideas that could help us solve the problem. The team mines the ridiculous suggestion looking for gold. This game trains the team to stop, consider, unpack, and explore suggestions offered by teammates.

Why: I am strongly tempted to disregard an absurd suggestion from my partner and move on to more “fruitful” ideas. When I do this, I am discounting my partner’s suggestions and treating their ideas as worthless. If I do this too often, my partner may feel unheard and disrespected.

When: When my partner offers an idea that is entirely off the wall and will not possibly work. When I see myself discounting my partner, I try to stop myself, and mine for gold.

Traveling Together

What: Sometimes the path forward and the answer is clear to us, but not to our partner. It is tempting to “get it done” and drag our partner along.

Why: Leaving your partner behind creates a tension in the relationship. Perhaps you feel that the work needs to get done today and the team cannot afford to be slowed down by your partner. In this situation, the team is missing out on a great cross-training opportunity. We may be robbing our team of the most valuable services that we can provide.

When: If you sense that your partner is not comfortable with a decision, check in with them first. Avoid plowing forward.

How can two walk together, unless they agree to do so? [reference]

Example: One time I thought the next step was super easy. My partner was not understanding my suggestion. I said, “let me try and see if it just works.” Unfortunately, it turned out not to be so simple. After going down several layers, I realized that I needed to stop, start-over, and involve my partner in solving the problem.

As a rule of thumb, the pair should never move faster than its slowest member.

If the person is not contributing to the team, involve your manager. One member of the team does not decide who belongs on the team.

Processing Strong Feelings

What: I use a set of playing cards to help me or my partner process strong emotions.

Why: Some projects are stressful. Life happens; events outside work may affect our emotions. Research shows that the verbalization of feelings reduces the power of the feelings. The utilization of different parts of the brain helps the processing of feelings.

When: If you observe in yourself or perceive in your partner, intense emotions that could affect the pairing dynamic, then consider this technique. Once I felt discombobulated and had difficulty in naming unfamiliar emotions, this exercise helped us understand what I was feeling.

“A growing body of research has revealed that labeling an emotion, or putting one’s feelings into words, can help to downregulate that affect” [reference]. “The results indicated that affect labeling, relative to other forms of encoding, diminished the response of the amygdala and other limbic regions to negative emotional images. …. These results suggest that affect labeling may diminish emotional reactivity along a pathway from RVLPFC to MPFC to the amygdala.” [reference].

How: Purchase a set of Mixed Emotion feeling cards available at amazon.com The cards are playful and helpful in getting in touch with emotions.

Mixed Emotions Card Deck

Here is an example interaction: “Are you willing to try an experiment with me? This exercise might help me identify some emotions that I am feeling. We each will look through a deck of cards and pull out one or two feeling cards with which we strongly identify. There are a lot of cards in this deck. Maybe you take the top half, and I will take the bottom half. Once we go through our decks, we then will switch. If we both want to select the same card, that is fine. There is just one in the deck though. Are you ok with this experiment?”

Go about picking your cards. When you both are done, explain why you identified with each of your cards. For your partner’s turn, try to make it as safe as possible. “I would like to know why you are feeling each of those emotions, but only share to the depth that you feel comfortable.” Some people will be eager to share their feelings and will even want to go first.

Example: One project had an aggressive deadline with a client who would refuse to prioritize the work to be done. The team suffered psychological distress [reference]. Several times I used this exercise to discuss my feelings and de-stress. Once I was not sure what my emotions were; the 60 cards helped me identify what I was feeling. After doing this exercise, I felt more in touch with myself, more at ease, and more connected with my partner.

Summary

I have developed these strategies from working through bad pairing experiences. Many of these strategies attempt to be preventative maintenance, things we can do to avoid the issue entirely.

You might enjoy the book I’m working on. The book describes how Pivotal leverages pair programming and several other practices so that its teams can survive major disruptions. Brady Bunch View

Collaborative Software Development ™