So far we’ve covered a number of tips for becoming a better pair programmer including the key to flexibility, being realistic, checking your ego, and assuming the best in every situation. For the last part of this four part series, I’ll be going over how to really know yourself as a developer so you can be the best pair partner possible.

Also, if you missed parts one through three of this series, you can find them below!

Part One - Tips and advice for creating a cohesive collaborative development environment

Part Two - Getting realistic and assuming the best

Part Three - Knowing your limits

Know your role

Very rarely is pairing an exchange between absolute peers. That’s a good thing though, because if that situation existed, there would be very little opportunity for exchange of information. More typically, partners will vary in terms of their technical, communication, and leadership skills.

The nature of the discrepancy often drives the goals of the pairing session. Those goals could include:

• De-siloing: Spreading knowledge about a codebase more broadly across an organization.

• Mentoring: Giving a relatively junior programmer more “face time” with a senior programmer to help the junior further their technical abilities.

• Onboarding: Exposing a new hire to a codebase and its peculiarities.

It’s helpful to know what is needed from you in a pairing situation. There are several roles you could be expected to fill, and these could change from project to project, or from pair to pair. Some examples:

Researcher

Perhaps you and your pair partner take turns being the “driver” (controller of the keyboard and mouse). Whoever isn’t actively driving could be the team’s researcher. After all, Stack Overflow isn’t just going to query itself! ;)

Tester

Sometimes, it’s useful for one partner to keep a command line or database connection open, to try out potential solutions to a tricky problem. This can save time, and it also means the driving partner doesn’t have the full burden of production on his shoulders.

Sounding Board

There’s something inexplicably different about the mindset you have when you’re doing the typing versus when you’re looking over someone’s shoulder. Being the “passenger” frees your brain up to think about things in a broader perspective, which can help your partnership. Whether this means remembering another place you need to implement the fix you’re working on; or a naming convention that has been used elsewhere in the application; or even a conversation you overheard in the office that has some bearing on what you’re trying to achieve, having a second brain against which to audition ideas is immeasurably helpful.

Mentor

One of the greatest suggestions I ever heard about pairing with someone much more junior than yourself was for you to do all of the driving, but type only what it was they told you to type. That approach forces the junior to actually think through the logic of the problem without feeling the direct pressure of actually putting pixels on the screen. If you have a clear advantage over your partner in experience or skill, it is incumbent on you to come up with some creative ways to help them feel empowered to figure out solutions to complex problems. It is not your job to feed them all of the answers!

Apprentice

If you are clearly much more junior to your pair partner, then your role in the partnership is to pry as much knowledge from their brain as possible. Notice how they work, what their thought patterns are, how they research problems, who they turn to when they get stuck. Not everyone is skilled at verbal communication, so don’t be afraid to ask questions when you’re unsure. By the same token, don’t be afraid to speak up when you have a suggestion. Your perspective is fresh, and therefore valuable. Even if your solution won’t work, you will learn why, and gaining insight is the whole point of the partnership.

Do your share

When you’re the pair passenger, it can be tempting to “zone out” and let your partner do all the work. No, no, no, and NO! Not only is this a lazy approach, but it is unfair to your partner, and does nothing to make you a better asset to your company. Do this often, and you’ll get the reputation for being an albatross, and you’ll find pair partners hard to come by!

Just because your fingers aren’t directly generating the code within your partnership, it does not mean you have little to contribute. You can still:

• Research error messages
• Try solutions at command line
• Grep the codebase for patterns that apply to the problem you’re trying to solve
• Shoulder-surf to watch for typos and logic errors
• Communicate progress to the client and the rest of the team
• Update tickets or stories
• Sketch things out on the whiteboard
• and, perhaps most importantly, encourage your pair partner when moments of doubt creep in

Don’t be lazy!!

Adapt and conquer

Some of these suggestions and tips will apply to your pairing situation, and some may not. You may have thought of many more than you want to share and I encourage you to do so in the comments section of this blog!

Just know that pair programming is FUN when it’s done right, and the final product is well worth the adjustments you will need to make.