Nothing Undone

A weblog, by Peter Jaros.

Mind-Meld Pairing vs. Coach-Pairing.

There are many kinds of pair programming. The two modes I tend to use are mind-meld pairing and coach-pairing.

In mind-meld pairing, the participants act as peers, two minds working in harmony. When it works well, it’s a truly beautiful thing. When you’re really on the same wavelength, as Kent Beck says, “You just point and grunt.”

  1. When it’s working well, participants naturally trade control of the keyboard. No one’s the “navigator”; you’re both navigating together. Someone types in the code because someone has to do it, but most of the time you both know what the code’s going to be before the keys are pressed. In fact, you’re probably both a few steps ahead of the typing.

  2. Mind-meld pairing remotely works poorly. Remote pair programming’s greatest flaw is latency. Unless you can guarantee an extremely high-bandwidth connection and/or you’re only pairing over ssh, there’s going to be noticeable lag as you control a machine remotely. Much as you can’t speak when you hear your own voice delayed, typing lag is fatiguing and and distracting. Just about anything that disrupts the flow can kill a good mind-meld session. I’ve only managed a few really good remote mind-meld sessions, and they depended on—for instance—agreeing to use vim over tmux.

  3. A great mind-meld session between talented developers will yield well-thought, well-factored, flexible code that is a joy to work with. When they say pair programming produces better code, this is the kind of pairing they mean.

In coach-pairing, one participant acts as a coach for the other. The coach is more experienced with the technology or style the pair is working with, and is teaching the other developer. Coaching is a great way to teach, and, personally, it’s something I love to do.

  1. Coach-pairing is most effective when the learning developer is driving. The coach should be verbally helping them through the process of thinking about what they’re doing. This requires a great deal of empathy on the coach’s part; his job is to figure out what the learner needs to be told, what he needs to figure out on his own, and what he’s better off skipping over for now.

  2. Coach-pairing works great remotely. It’s interacting with the remote machine that’s troublesome. But watching someone work on their machine and talking them through it works just fine.

  3. A great session of coach-pairing does not yield the most amazing code. That’s not what it’s for. A session of coach-pairing will yield a better developer in the junior partner. It will also result in better code than that developer would have written on their own.

These modes are fluid. During a pairing session, I sometimes find we move easily from me coaching to us mind-melding to my pair coaching me as we work on different areas. Most sessions, though, are primarily in one mode or the other.

It’s valuable to be aware of which mode you’re in. There’s no sense in being mad at yourself for producing less-than-incredible code during a successful coaching session. Likewise, if a codebase needs some improvement, try consciously pairing people who can mind-meld to make that happen, even if that means the more junior members of the team get less training.