a friend asks what to do about a bad pair. that’s a juicy one, and prods me to muse.
why do we pair? it’s one of the techniques we adopt to increase productivity. that’s measured in geekery by insights per hour, or such like.
maybe if we understand what makes good pairing, we can get closer to some possible remedies for bad pairing? good pairing involves a bunch of otherwise disconnected-seeming aspects. these form an interactive context in which the pair operates. if some of those aspects are flawed, seeing the flaws would let us throw out some ideas for making it better.
1) best-pairing happens when we’re physically comfortable. if one or both of us are physically unhappy, let’s figure out how to change that. makes me think of things like monitors, evenly split seating, font size, each side experiencing equal access, visibility, and so on.
2) best-pairing happens when we’re unafraid. two factors here. am i afraid of her, or her me? are either/both afraid of the problem? a key danger: does one of us confuse the code with the self that made it? that’s a huge source of crippling fear. i’ve had many pairs whose self-identification with the code turned them into a beast i shorthand as a penis monster. these folks are so afraid to be wrong-in-the-code or wrong-in-the-pair, they push away every attempt to collaborate.
3) best-pairing happens when at least one person has a clue about how to proceed locally. this is always a shifting judgment call. sometimes i’m with a pair and we’re so clueless we split up to go discover 3-4 dumb ideas that might work. it helps to see that and do it. i stay alert to the times i need to not pair, but still not alert enough, cuz i miss the cues i’m giving me and resist breaking too long.
4) best-pairing happens when we verbalize more-or-less continuously about what we’re doing. ideas-to-words-to-hands is not an inherent skill. not everyone can quite manage it, tho most can be taught some baseline of it. the key is to know when you’re doing it and not, and to accept the occasions when you can’t, and speak to them, too. sometimes i say, “hey sugarlips, gimme like five minutes to jiggle this just so, quietly. i promise we’ll revert if it doesn’t work.”
5) best-pairing happens when we both have either the big picture or the small picture. that is, we need some shared vision at some level. back in the clueless context, i said i stop when we’re both clueless. when we start with one of us having the clue and the other not, we go to whiteboard for 2 minutes & move it across there. i might not still get her idea, but i start to, and can get the rest in situ.
6) best-pairing happens when we pair promiscuously. i’m tempted to just leave that there, but will push it a little further. i like to rotate at minimum on half-day boundaries. i prefer the king-moves model, where the person who’s been on the task longest leaves. promiscuity in pairing can really help “bad pairs” to learn, and i encourage it.
7) best-pairing is highly spontaneous, with lots of unplanned and unplannable micro-interactions. i find techniques for pair-structuring, like driver-navigator or ping-ponging, to be at best learning aids for very junior-at-pairing pairs.
8) best-pairing is fucking intense. it can be quite grueling, emotionally, intellectually, even physically. pay very close to your experience, and watch for the signs you’ll get from you that you need a break. take your own feelings’ advice.
finally, a few words on how i introduce pairing to a team that hasn’t done it.
i don’t. that is, i don’t mention pairing at all. i build a good pairing station and i have folks come visit me there. we work on problems together, that’s all. at my excellent station, that’s all. i rotate that around the team. i’m aiming to create joyful experiences for them of working 2-on-1. i don’t instruct, and i don’t call it pairing.
when i do finally get to it, it’s usually because the team is experiencing the pain of silos. i make a proposal, let’s block out 11 to noon every day for an hour of pairing. we lottery the rotation, and we coin-flip whose problem we work on. i travel that experience around the team a few times before i ever mention pairing.
by floating around watching those interactions i develop a sense of who’s liking it, who’s not – and possible reasons why not. if it goes well, we extend the time. if that goes well, we extend it some more. eventually, we’re pairing at least half of our day. at that point we can drop special times altogether and just declare ourselves a pairing team, where we all seek to pair whenever we can.
the most common flaws of the ones i’ve mentioned above: unknown physical discomfort. for instance, i’m pretty deaf. you can’t tell most of the time, cuz i’m good at faking and lip-reading and what-not. it’s often invisible. but harder to mask when pairing.
second would be the penis monster. this is always a brutal challenge from a coaching point of view. how do i help people not self-identify? mostly i model: i screw up all the time anyway, and i highlight me screwing up, laughing, moving on. i do large reviews & teach them the review motto: “i am not my code.”
above all, i remind myself and the bad pair’s victims: pairing is a skill. it must be learned. we all have different skill levels. all over the team, we have masters at X, juniors at Y, and so on. we cope with this in lots of ways, but most of them are attempts to bring the junior’s skills up to the minimum baseline. the same exact thing applies to pairing itself.
if you just can’t understand java, after a long stretch working w/the team pulling you along, we have to part ways. if you just can’t learn pairing, after a long stretch working w/the team pulling you along, we have to part ways. but as w/the java situation, in most of my coaching career, the weak-java or weak-pair gives up on us before we give up on him.
that’s all i got for the moment. feel free to poke/prod/ask whatever followups hit you.