Let's start by positing that we're doing some form of pairing. Further, let's posit that we're pairing for more than just for writing code. So, then, we should be able to pair on about anything.... right?
I don't actually know if that's the case. I do know that I find some things a lot harder to pair on than others. I'm good with pairing when we're: doing an exploratory test session (especially if I'm not the one driving); or teaching/learning something concrete, like how to install the software; or doing general coding. I have a really hard time pairing in some other situations, though.
This is a bit long, but bear with me through this example. We have been working on some code to interact with Jira. This is a classic thing you pair on - we had some base code and we needed to add the ability to set the "affects version" when the ticket was created. But this particular thing was extremely frustrating. It should have been a really simple problem to solve but the documentation is sketchy at best and it just wouldn't work. We wound up spending a good amount of time with Google, staring at Data::Dumper outputs for similar data structures (especially Jira's "components"), and ultimately just poking at the darn thing. Eventually it worked, but it was very hard and very frustrating. Oh, and it took both of us to solve it, so in the end it's probably good we were pairing. I won't bore you with another example, but there are a few other times when I've been working in a pair with someone and just found it more frustration than I would expect.
So what makes some pairs so hard?
I know in part what is NOT the problem:
- The people I'm pairing with. I can pair with one person and do great, and pair with that same person another time and have it be a hair-tearing experience.
- The setup. Again, this one is the same across pairs, even when some are easy and some are hard.
There are only two things that I have figured out that make pairing consistently hard.
When I'm writing the first draft of a document, I can't do it while pairing. The words simply won't come, the structure is all kinds of skewed, and there is just no cohesion. This has to do with the writing flow state, I think. I simply can't type as fast as I can think, so the words in my head are a good 5-10 seconds ahead of what the other person can possibly hope to see. Stopping to let the other person (and my fingers) catch up just breaks the train of thought. And we wind up with a mishmash of short thoughts that just doesn't hang together. Those short thoughts represent the only times we were truly thinking together, and it's in spurts.
I should note that revising documentation is a whole different story. That really easily benefits from multiple eyes.
In the example I described above, one of the things that was the most frustrating is that we were doing a lot of what I'll loosely call research. There was a lot of Googling and following threads, tickets, documentation, APIs, and then trying something based on the slim leads we found. The trouble was that there were a million ways to go with this, each legitimate. And when I do something like this on my own, I'm moving fast. (I'm a pretty good data sifter.) I'm following breadcrumbs of solutions or partial solutions or failed solutions, attacking the problem from different angles, and constructing a representation of the path to the solution in my head and revising it constantly between my code and the various resources I found. Having to take someone along with that thought process is very difficult.
This is exacerbated, I think, by the fact that when I'm in this mode it's because we're working on a problem that's harder than I expected it to be, so I'm already a little frustrated ("I should be able to solve this already!").
I don't know how to make these pairs easier. Practice, in part, I think. Learning how other people solve these kinds of problems might help. Slowing down and walking other people through the techniques I use is probably a useful step.
Definitely more thought required here...