Reading Time: 6 minutes

You’re thrilled; tomorrow, you get to pair with the one developer on your team who really knows about iOS storyboards. Or you have an excellent mentor outside of work who can squeeze in an hour and a half pairing with you twice a month. How do you make sure that you walk away from these sessions having learned as much as you can?

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

It’s in your interest (and your pairs’ interest—we’ll get to that later) to make the most of everything that your pairs might have to teach you. Keep in mind that just because someone knows a lot of stuff doesn’t mean they’ll be effective at transferring that stuff from their brain to yours. You want to aid that transfer as much as possible; luckily, with pairing, you have a few helpful practices in your employ.

Parts of this post will read like a mirror image of the earlier post in this series about enabling your pair. The ideas are the same, but now you are the primary context receiver instead of the primary context provider. That said, here are some helpful concepts to keep in mind:

Learn Some Context On Your Own Beforehand

This is not always possible—say, if you don’t know what you’ll be pairing on with your colleague or mentor. But if you know which stack or application you’ll be working on, you have time to do a little pre-reading. Focus on those aspects of the task that your pair will know more intimately than you do. It helps to go in with some ideas about first steps because your pair will find it much easier to guide you if you have a starting point and a direction to go, as opposed to walking in completely disoriented. Have an idea of which files you need to open and where you should expect to be modifying those files. Spend a little time cogitating on why the system is architected the way it is. If something doesn’t make sense to you, keep it in mind. You can bounce these questions off your pair during the pairing session to learn helpful nuggets about why the system does what it does. You might even unearth some things that your pair wonders about, too!

Walk in Prepared to Slow Your Pair Down

If your pair knows the system better than you, chances are that they will want to move through the work faster than you are able to keep up. In these situations, I want to empower you to stop your pair, ask questions, ask them to repeat things, and generally encourage them to slow down to your speed. Don’t worry if your pair finds this frustrating; you’re helping the team as a whole by slowing them down. Why? Well, if your pair blazes through the work without your help because they’re moving too fast for you to learn, then the next time they’re sick and this task needs to be done, they’re under pressure to get back into the office. You might have been able to do the task in their stead, but you can’t because you sat silent while they did it alone the last time. By slowing down your pair, you’re being a team player; by responding poorly, your pair is not. And if your pair doesn’t understand that, then his boss certainly will.

This works the other way, too; if your pair does move at your pace, or responds positively to your requests for them to slow down, they will very much appreciate it if you send that positive feedback up the chain.

You Do the Driving

I explained this one in the article on enabling your pair like this:

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.

It’s scary to sit there and drive when your pair could knock out the task in two seconds. It’s also one of the most effective learning exercises both of you can do together. You’re the bottleneck of work getting done, so progress has to move at the speed at which you understand what’s going on. This is critical for your learning. Your pair cannot make things go faster by doing the work for you; instead, they can make things go faster by explaining it to you more clearly and explicitly. Often, your pair will come to discover some weaknesses in their own understanding when asked to explain the systems they know to someone else.

I have gone so far as to unplug my pair’s keyboard to ensure that I am the driver. If you’re remote, you can do it by disabling your pair’s ability to control your computer. Obviously, do not do this unless you have a positive and familiar working relationship with your pair. Explain that you are doing it, and explain why you are doing it like this: ‘May I unplug your keyboard? I would like to make sure I understand what we’re doing, and I want to test myself by forcing myself to do all the driving based on our conversation and your instructions.’ That way they don’t think of it as you testing their ability to explain.

In Summary

Make sure you learn as much as possible in your pairing sessions with programmers who know more about something than you do. Familiarize yourself with the material beforehand, practice requests for your pair to slow down, and ask your pair to let you do all the driving. In the process of working with you, your pair will become a better expert because they will get practice teaching and might discover some gaps in their understanding of their craft. Also, by enabling you to do the work that they do, your pair can demonstrate their immense value by helping the team scale its operations. Plus, they’ll get more freedom at work because your project’s operations can go on while they focus on other things like leadership, mentorship, or technical trailblazing. You, in return, get to level up your skills and tackle a harder, more diverse set of projects.