How often do you pair program and what do you make of them?

I used to work on a consumer-facing team and did some pair programming there. It was useful when working through subtle concurrency issues during a major site re-design.

I don't pair program today but sometimes do interactive "let's look at code" Zoom sessions.

Pair programming is fundamentally not scalable as it sucks up multiple engineers' time, but there's a ton of nuance there. I have a lot of thoughts on the topic, so I'll split it up into multiple comments.

What I Generally Do

• My default operating model is to not pair program, and that's generally what every team I've been on has been like.
• Even with my mentees, I generally pushed them to figure things out on their own; however, I would pair program with them as a safety net if they really needed it.
• Pair programming at Meta was pretty rare as you need to move fast there, and there's a big emphasis on becoming very independent. I've heard similar things about other Big Tech companies.
• If I were to put a frequency on it, I pair programmed maybe once every 2-3 months, usually as the driver. I have rarely pair programmed as the "passenger". However, I have been a tech lead for most of my career (after 1 YOE, I joined Course Hero as their Android TL), so I'm sure my experience is skewed.

When Does Pair Programming Make Sense?

• Onboarding is by far the most powerful use-case IMHO. It provides a rapid-fire way for you to understand the codebase since you can easily ask follow-up questions and builds up relationships between you and other members of the team. Something else to keep in mind is that onboarding doesn't only apply to when you switch teams/companies - You are onboarding when you're changing tech stacks as well, even if you're staying within the same team.
• In a remote environment, pair programming is valuable as it fills in some of the void from not being in person, particularly the "learning via osmosis" you get when you're in an office alongside everyone else.
• When you're earlier on in career, pair programming will pay higher dividends too.

So What Should You Do?

• If you feel like this pair programming works for you and the teammates you're pairing with, by all means, continue doing it!
• The main thing I recommend here is to get the maximum value from these pair programming sessions. When you're out of the onboarding phase, the purpose of pair programming should shift from tactical (i.e. "teach me how this codebase works") to more strategic/high-level. To better capture what I mean here, here are some questions you can ask while pair programming with a more senior engineer:
  • "How did you decide on this approach?"
  • "How do we know that this code covers all edge cases and will work at scale?"
  • "What principles do you follow when you come up with a system design or decide between 2 ways of coding something?"
  • "If I wanted to tackle this problem completely on my own, what tools and processes can I follow to do it?"
• I think in this post-covid world, pair programming is a much more important tactic.
• Since you're not junior anymore, consider being the "driver" and proactively volunteering to pair program with others as well, especially new folks who join your team.

For more tips on what the more fundamental software engineering skills you should learn from pair programming, I highly recommend this course: [Course] Frontend System Design Masterclass - Building Playlists