# Pairing Guidelines

DevFeed: [Pairing Guidelines](<https://devfeed.tech/articles/pairing-guidelines-21792.md>)

Original publisher: [Read original article](<http://blog.cleancoder.com/uncle-bob/2021/01/17/Pairing.html>)

Published: 2021-01-17T00:00:00Z

Content type: article

Language: en

Sources: [Robert C. Martin](<https://devfeed.tech/sources/robert-c-martin.md>), [The Clean Code Blog](<https://devfeed.tech/sources/the-clean-code-blog.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [pairs](<https://devfeed.tech/tags/pairs.md>), [programming](<https://devfeed.tech/tags/programming.md>), [projects](<https://devfeed.tech/tags/projects.md>), [team](<https://devfeed.tech/tags/team.md>), [time](<https://devfeed.tech/tags/time.md>)

## AI overview

The article presents practical guidelines for pair programming. Pairing is most valuable for non-trivial but not deeply difficult programming work, while very deep problems may require concentration and trivial tasks usually do not justify pairing. It recommends voluntary, informal, short sessions and emphasizes balancing collaboration with individual work and team familiarity.

## Source excerpt

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 s