Everybody pairs from time to time. It is a rare programmer who has not sat down with another programmer to look something over or help find a bug.

Deep problems, that require much heavy thinking, do not often lend themselves to pairing. The interaction between the programmers tends to disrupt the necessary concentration.

On the other hand, it is not uncommon for programmers to get caught in a problem that they think is deep, but for which there is a much simpler solution that another programmer could quickly see. So it is wise to start deep problems with a pair, or even a mob, but then break it up when it becomes clear that the problem is irreducible.

On the other side of the spectrum, there is no good reason to pair on trivial matters. Fleshing out a list of error messages, or loading fifty fields into a form are relatively mindless activities that do not require the scrutiny afforded by pairing.

Then there is the vast middle. This is where pairing/mobbing are most valuable. These are problems that are non-trivial, but also not particularly deep. This is 90% of all programming. Pairing on this type of code keeps that code well tested, well structured, and as simple as possible.

Pairing should always be voluntary, never be forced, never be scheduled by a manager, and never tracked. It is an informal process that is entirely under the control of the individual programmers.

Some people can’t, or won’t do it. That’s ok; but it may require that their participation in certain projects be curtailed.

Pairing sessions should be short-ish. 20-40 minutes at a time. (Tomato sized) With no more than three or four consecutive sessions of that length. This is not a rule, just an informal guideline.

Not all code that would benefit from pairing, should be written by pairs. A mature team might pair 50% of the time, or even less. During the pairing sessions, a large amount of code will be reviewed; far more than the pair is actively writing; and thus the benefits of pairing will be seen in very large swathes of non-paired code.

Bottom line: Don’t be a jerk. Pair sometimes, don’t pair other times. Pair enough so that you have a good grasp of the overall system, and know enough of what your teammates are doing that you could step into their roles if the need arose. Don’t pair so much that you hate your job, and your teammates.