The lone coder has a lot of advantages. Working in a personal cave away from all distractions, a solitary coder can do amazing things: Conquer a new game engine, command a drone circus, or build an empire of microservices.

But what happens when you’re all alone and you come up against an adversary you’ve never faced before? What if your game engine needs some complex physics modeling, or 3D positional audio, or what if you’ve just never used React or Redux before, and you just need an experienced guide to show you the ropes?

What if you’ve been chasing a bug for 3 hours now, and all you have to show for it is frustration, self doubt, and maybe even a bit of creeping imposter syndrome?

Pair programming might be able to help.

What is Pair Programming?

Pair programming is a software development methodology that works a bit like airline pilots: You have a captain at the controls, and a navigator.

Let’s keep this grounded though. Imagine you’re on a cross-country road trip to your shipping port. The driver has the keyboard and mouse, and the navigator drops helpful hints, course corrections, or pearls of wisdom along the way.

The navigator can even take over driving once in a while. Sometimes you have to see something done before you can understand how to do it.

Mentorship Culture

I am a strong believer in building development teams with a culture of mentorship baked in deep. No developer should ever stay stuck on a problem for more than 10 or 20 minutes. If you’re struggling, you should be able to reach out and ask for help.

Helping and mentorship should be strongly encouraged on your teams. Most dev team cultures are set up to prize ticket velocity over all things, and that can have a strong chilling effect that blocks teammates from collaboration. That’s the last thing you want to do on your teams. Read “The Essential Guide to Building Balanced Development Teams” for more on that topic.

Pairing Styles

There are 2 common styles of pair programming, and both are valid, though I do have a preference as you’ll soon see.

100% Pairing

Some development teams pair 100% of the time, all the time. Team members are paired up with partners, and there is always a navigator watching every keystroke.

That works great for live feedback, knowledge sharing, and realtime code review. However, after discussing the culture with members of 100% pairing teams, I decided against doing the same for my teams.

Ad-Hoc Pairing

Sometimes, pairing partners like a little variety. They want a little uninterrupted alone time. Sometimes when you’re coding and you’re on a good track, and you know where you’re going, you just need a bit of silence so you can concentrate and get the job done. It’s hard to get into a state of flow if there’s somebody always reading over your shoulder and talking in your ear.

Instead, I like to pair when I’m stuck on something and I just need an extra set of eyeballs to catch whatever it is that I’m blind to in that moment. Sometimes just explaining it to somebody else can be just what I need to break through.

Every developer makes stupid mistakes. Anybody who tells you they don’t is a liar. We should never feel ashamed to ask for help. I frequently ask for help and I’ve been doing this most of my life.

When you feel you’re getting stuck, and you want to avoid wasting another hour banging your head against a brick wall, call for help.

Pair programming to the rescue.

Pairing Tips

Here are some things that work well for me:

1. Use a remote-control app like Zoom Basic for interactive remote pairing sessions where either party can take control and drive.
2. Pairing requires high-bandwidth. Sometimes video chat is really nice. If you don’t have Screen Hero, try Google Hangouts.
3. Before you dive in, clearly explain what it is you’re trying to do, what you expected to happen, and what actually happened. Demonstrate the problem by running the code.
4. If you’re helping somebody else, let them drive. People learn better when their brains are tasked with something active. They’ll remember how to do it better next time if they’re driving.
5. If explaining something is clearly not working, take the wheel. Show, don’t tell.
6. Don’t feel stupid or inadequate if the helper needs to take the wheel from you once in a while. Be open and receptive to the help. Stay tuned in. Pay attention and try to follow along.
7. Once you feel confident that you’re on the right track, see if you can strike out alone again. I know it doesn’t always feel like it, but we learn best when our brains are challenged. Be brave!

Conclusion

Pair programmers are:

• Great moral support.
• Good listeners and sounding boards.
• Heroes, coming to the rescue when a teammate is in trouble.

Never hesitate to step up and be a hero. Even if you don’t feel confident that you can help. Just having somebody to listen to the problem can sometimes be enough to trigger a breakthrough.

Now stop wasting time banging your head on the keyboard, and ask for help.

Need help right now?

1:1 Mentorship with Eric Elliott

Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript with Eric Elliott”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.

He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.