I find it useful for brainstorming through complex problems. It is also useful for combining code review with programming, which can sometimes be faster than the time it takes for a code reviewer to understand your code without any pairing.
kanishka
dimitarvp
Yeah, exactly. I can’t use pair programming 100% of the time, it exhausts me mentally and physically and doesn’t allow for creative alone-time when you are trying to figure out a problem (somebody more experienced in the said problem directly telling you the solution does not exactly inspire you to think).
To me pairing was indeed most useful for:
- Brainstorming, AFTER you have both given the problem some thought and still can’t quite find your way out of it;
- Code reviews.
I respect people who use it all the time but I suppose I always found companies that are scared to use 2 devs for what they perceive only 1 should be able to do, don’t know. But I am also glad I wasn’t forced into 100% pairing.
If I wanted non-stop interaction I never would have migrated to remote work in the first place. 
I would have stayed in offices.
3
sodapopcan
This was a big thing I didn’t mention. Really I just put it as “we don’t do code review when pairing”. This is one of the contributors to pairing being faster. I personally really hate code reviews. Obviously you need them if something was written by one person, but if done properly you’re pulling someone off of what they are doing so they can start reading and trying to understand brand new code. Then you get into covos like, “Why didn’t you do it this way?” “I thought of that but because of this I couldn’t” and so on and so forth. Those convos are much better to have with two people with the same context while the code is being written. At worst code reviews are people being pulled off of what they are doing just so they can say “LGTM!”.
Of course, I’ve never worked somewhere that had a really good code review process.
1
Nezteb
I personally am not a fan of pairing sessions that go on for longer than 15 minutes unless both of you are in a good groove and find it productive. Pairing sessions also don’t always need to consist of pure coding.
My process is usually:
- Come up with a goal for the pairing session. Talk to the person you will be pairing with about these beforehand over text.
- Maybe you were just assigned a feature ticket and you simply want to talk it over with another engineer for a bit and develop a plan: talk about overall architecture and logic flows, figure out what files/modules you probably need to modify/create, figure out how you might test your changes, etc.
- Maybe you were assigned a bug ticket but you’re having trouble reproducing it. Two heads are better than one; you can pair together to figure out reproduction steps.
- This also applies to code review; maybe you just want to sit down with someone while they review your code.
- Get on voice chat (video optional) and start a live coding session if your tool supports it (e.g. VS Code Live Share). If not, just share each of your screens.
- Talk about your thought process out loud; rubberduck debugging is a wonder.
- Feel free to write things down as comments/TODOs/pseudocode instead of actually implementing everything during the pairing session.
- If you haven’t made progress within 15 minutes, agree to adjourn the meeting for a bit and take time on your own to think and experiment. If you have made good progress, there’s no need to stay on the call for longer unless both of you agree it’d be worthwhile.
- It’s worth being explicit about what each of you will do after the call. Presumably you will keep working on your task, but clarify what your colleague will be doing. Will they also work/think on your task, or will they go back to whatever they were doing before?
- Don’t forget to take breaks! Talking for long(ish) periods of time can be draining.
- Don’t immediately start another 15-minute session with the same person unless you or they have come up with some new idea or breakthrough.
- If that hasn’t happened after a decent period of time (30 minutes, an hour, etc.), you might consider requesting to pair with a different colleague and see if their experience/perspective gives you more insight.
- Rinse and repeat.
3
kanishka
I actual like it for brainstorming deep technical problems like designing a library, before thinking alone, and then breaking off and polishing after coming up with a direction sketch.
1
tcoopman
I won’t add too much because a lot of good information has already been posted here.
One thing I want to add is that a lot of people are commenting on “I” do/don’t always like it. I’d like to argue that things like pairing and especially mobbing (or known as well as ensembling/teaming) is that it’s not optimised for personal productivity but for work/ team effectiveness.
It’s not something intuitive but personal productivity of every developer in a team doesn’t lead to the best team productivity necessarily.
2
sodapopcan
This is so important and why I don’t focus on the mentoring aspect when talking about the merits of pairing. For example, @linusdm said:
In my mind, letting this person run wild on their own is about as bad as telling a junior to solve something however they want. I don’t want this person on my team or even in my org if they are going to demand to work solo all the time and produce work only they can understand. I’m just speaking personally as someone who prefers to be in collaborative environments—lots of orgs are full of these people, I just don’t want to work there 
2
joey_the_snake
In my opinion it is awkward. There are ways to collaborate and share knowledge without having to be beside each other while coding.
I also found (in my experience only) that orgs adopting this tend to also encourage “collaboration” in toxic ways. i.e. accepting poor solutions that you know will cause prod issues to not hurt people’s feelings. Or giving medal of honors to people for creating poor solutions and then sacrificing their nights/weekends fixing them when customers are affected.
edit: sorry I didn’t mean to reply to you directly. just meant as a comment in general. not sure how to fix it.
1
sodapopcan
Ya, like any methodology it is easy to get wrong. Like I had a very good experience with Agile because the org I worked at studied the material (ie, they RTFM’d) and understood how to use the framework without drinking too much Kool-Aid. All my other experiences with Agile have been orgs blindly adopting random SCRUM practices and forcing everyone to do them without truly understanding why (for example one place story-pointed everything, often multiple times, but no one ever looked at them). It’s the same for pairing.
For what it’s worth, my experience was not at all like you described. My 100%-pairing job is the only job that I never once had to work evenings or weekends—unless I got pinged while on-call which, btw, happened only once in my 3.5 years there. Working outside of office hours was actively discouraged and if you did it anyway, you would receive no accolades for it. Places that like are rare, though.
And ya, I think it’s impossible to delete a “respond-to” mention. I’ve accidentally done that several times before.
2
tfwright
Counterpoint: I have found that too often people will not accept CR criticism unless it’s something trivial, usually actually addressed in official guidelines. If you actually bring up something tough like separation of concerns, they will not actually consider feedback and insist their solution is adequate, or even better, without even bothering to offer very good reasons. Even if you offer very concrete advice like pointing out that recursion could solve a problem in a much more elegant and clear way, you can get responses like “I tried that and it didn’t work” and you are forced to approve often significantly suboptimal code unless you literally implement it for them. I’ve noticed this is a lot worse in 100% remote orgs, and is one aspect I definitely think is detrimental vs. being able to establish regular face to face communication with someone. Admittedly, remote pairing doesn’t fully solve that problem, especially if it’s infrequent, and it’s obviously also related to culture and personality etc, but it’s definitely a pattern I’ve noticed. Pairing can build both the rapport and shared ownership necessary to avoid the siloing that can result when this sort of thing gets out of hand.
2