It’s not easy to start pair programming. Most of us don’t get much of a chance in school, and often our first programming job is on a team that hasn’t done it much (or at all) in the past. Still, it’s worth
making the effort.
So here’s a quick-start guide to help get your pairing efforts off the ground: the benefits, the vocabulary, and different formats you can try as you’re figuring out which style works best for you and
your teammates.

A willing, happy pair is better than the person who is “best matched” in terms of experience or domain expertise.

Why pair?
It’s a great way to share knowledge. You’ll learn, teach, and work with code you might have missed. Often you understand the code better at the end of a pairing session because each of you were asking “why?” more than when you work alone.

You’ll get some good instruction. Pairing can be particularly useful for new hires. It’s a great way to get to know your team, learn about coding styles and expectations, and find who’s the right person to
ask about a given topic.
It helps you stay focused. Checking your social media site of choice is much less appealing when there’s a person right there to talk (and
code!) with. You’ll write better code. You don’t write code much faster with two people, but you write it with fewer bugs, which gets you to “done” faster in the long run. There isn’t a lot of research to back this up — purely anecdotal. Personally, I think the other reasons are more compelling. If you’re thinking “aren’t these the same benefits of code review?”, then yes! You caught me! Pair programming is indeed a lot like code review. However, pair programming has one major advantage over code review: you review in real time. That means you get to make corrections to your code before you’ve added a bunch more code on top of it. If that all sounds amazing, that’s because it is. So let’s get started!
Finding a pairing partner
The first thing you’ll need is a pairing partner, who can be anyone who wants to pair with you. A willing, happy pair is better than the person who is “best matched” in terms of experience or domain expertise. And the best way to find partners is to just start asking. If your teammates don’t take the bait when you bring it up casually at lunch, try sending a meeting invite. They might take your pairing invitation more seriously when there’s a super-official-looking calendar entry for it .

Offering to pair up on the other person’s task can be a good way to entice people who’ve never paired before. They may politely say they don’t want to “waste your time” by working on their task, but push back on that. If the task is worth their time do in the first place, it’s probably worth your time to pair on it. Besides, when you’re new to a team, pairing is an excellent way to get up to speed on the code base. The time they invest in pairing with you will pay off quickly in terms of the value you add to the team. That said, some people just don’t love pairing. It’s alright (and sometimes necessary) to push a little bit, but ultimately, be willing to gracefully accept a “no.”

Once you’ve got a partner in (crime) code, how often you pair is up to you and your team. Just make sure you’re all on the same page since pairing plans may influence how many tasks your team takes on in a given timeframe. If possible, begin with two sessions a week with different people on your team. That way you’ll see what it’s like to pair with different people.

Pairing sessions can range from 90 min one-offs to pairing all day, every day for a full sprint. One team found many short pairings was better, but your milage may vary. I recommend starting with 90-minute sessions and adjusting from there.

Finding a pairing style that works for you
Understanding the terminology and different styles of pairing will help you get off on the right foot. Let’s start with the vocab:
Driver: Does the typing; bounces ideas off the navigator; gets the up-close view of the code.
Navigator: Looks for logic problems, bugs, and better implementations; acts as a sounding board, and thinks ahead to potential problems; gets the macro view of the code. As for styles, I’ve tried or witnessed four of them. Try starting with “the noob” and fall back to “the distracted” when you need to look
something up. Build up to “the classic.” Note: the names below are entirely my own invention.