Maybe you are a senior developer in your role at your place of work. Maybe you happen to have most context on a given tech stack or application. Maybe you’re orienting a new team member, or you’re conducting an interview with a candidate using your code base. In all of these cases, you are in a position to bring your programming pair up to your speed on the project.

This is part two in a three part series about advanced pair programming.

Your ability to bring other programmers up to speed makes you unspeakably valuable to your team. If you can spread your knowledge and skills to other programmers, you give your team the ability to scale. I don’t have to tell you how much money companies shell out to make sure their apps and infrastructures can operate at scale; it’s that important. But scaling the team behind those apps and infrastructures? That is even more critical to the scalability of the operation. (Remember this at your next compensation review meeting).

But before you go asking for that cash, let’s make sure you really do know how to transfer your knowledge and skills to your programming pair.

First Thing’s First: This is Not a Speed Drill

If your dream is to demonstrate to everyone that you’re a super-l33t speed hacker, pair programming probably isn’t for you. The increased productivity of pair programming does not come from raw speed; it comes from making fewer broad-reaching mistakes, and it comes from sharing context so the operation doesn’t get bottlenecked by a single person who holds all the context and happens to be out sick or in a meeting.

All that having been said, speed is especially not of the essence when ramping someone up during pair programming. Doing so will limit the amount of context that you successfully transfer to your pair, and a speed-focused environment will discourage your pair from asking you questions. So, bring a hot cup of tea to the pairing station with you and prepare to exercise some patience. Believe me, you weren’t a speed-typing wizard the first time you did any of this either.

Hands Off Your Keyboard

I have been the less-context member of a pair on hundreds of occasions in my programming career. My pair-mentors have fallen into two distinct categories:

1. the ones from whom I learned nothing and with whom I lost confidence in myself.
2. the ones whose knowledge, advice, and principles I still apply, sometimes years later.

I can categorize these two groups of pairs based on one single practice.

The ineffective ones did not let me type through my sticky spots. Instead, they took the keyboard and started driving the moment I became lost or confused. The really effective ones almost never touched the keyboard while pairing with me…but especially not in those lost moments. Even if they visibly, desperately wanted to do it.

Imagine this like doing a bench press or some similar weightlifting workout. If your spotter swipes the barbell away from you the second you betray the fact that it feels heavy, you’re not going to get stronger. Strength comes from struggle. You have to try to push through your sticky spots, and a good spotter knows how to let you do that while keeping you safe.

It’s the same with programming. I have explained the idea of driver-navigator safety in pair programming before. So I’ll quote that explanation here:

Pair programming generally includes two roles—one for each of the people in the pair. One person will play the role of driver—typing on the keyboard. The other person plays a navigator role; this person thinks a few steps ahead of what the driver is typing and tells the driver where to go and what to implement. We keep these roles separate so both pairs have context at all times. The navigator calls the shots, but the shots have to go through the driver to end up in the code—so the navigator can’t go faster than the driver’s capacity to understand what the navigator is suggesting. This forces the navigator to explain things clearly, offer good reasons for their suggestions, and slow down—which encourages critical thinking and better solutions.

If the same person is both typing and navigating, then that person now has all the immediate context about what’s going on, and the other person in the pair might lose context. So the two roles are an important safety check for communication and shared context.

This is especially important when your pair is confused, because that is the exact moment in which your pair could lose context. Practice safe pairing. One driver, one navigator. And if you’re the pair with more context, you probably should navigate.

Imagine Yourself as a Support Structure

You can allow your pair to struggle, to type slowly, to think for a minute. While that’s happening, though, you can provide the context to help them figure out what comes next. If they’re new to this application, for example, you can guide them to other parts of the code base that provide them with helpful examples of solutions to problems like the one they’re trying to solve. If they’re new to the stack, you can provide historical context about how the language, framework, or surrounding community does things. You can encourage your pair to talk through what they’re thinking and, as they have questions, answer those questions.  You can even provide encouragement if your pair is getting frustrated, or offer them patient silence when they need to hear themselves think.

Think of yourself as the second fiddle in this band. Your job is to fill in where the first fiddle needs depth or backup. In this process, you might be shocked at how much you learn from the person you thought you were ramping. While you have context on some things, your pair has context on other things—things that are just as important and useful as the things you know. And maybe, just maybe, their context from the outside world can help with some of the challenges that have left you stumped. That’s part of the point of pairing: it’s a two-way exchange of context. Give yourself the opportunity to learn from new perspectives.

To Summarize

When you can enable other people to do the things you do, you become extremely valuable to your team because you make it possible for your operation to scale. The role of enabling other programmers while pairing comes with some important considerations. First, lose the focus on raw speed and prepare to take your hands off the keyboard. Especially allow your pair to type in those cases where they seem a little stuck. Think of yourself in a supporting role and provide the context, suggestions, and encouragement that your pair needs along the way. With those concepts in mind, you’ll be scaling your team in no time.