Pair programming and mob programming: Writing code together

In short: In pair programming two people write code together on one computer: one types (driver), the other thinks along and checks (navigator).

In more detail: Working on code in pairs seems slower at first but often brings fewer errors, better design and more knowledge sharing. Especially in training it is a good method for learning from each other.

In Depth

Roles

• Driver: types the code, focuses on the current line.
• Navigator: thinks ahead, watches for errors, structure and edge cases, looks things up in documentation. The roles are swapped regularly (every 10 to 25 minutes, for example with a timer). Both talk aloud, otherwise it is just two people in front of one screen.

Variants

• Ping-pong: one person writes a test, the other the implementation (with TDD).
• Remote pairing: screen sharing or shared editors (VS Code Live Share, Tuple).
• Mob programming: the whole team works on one computer, one driver, all others navigators. Good for hard problems or onboarding.
• Strong-style: “For an idea to get into the computer, it must go through someone else’s hands.”

Advantages and limits

Advantages: instant code review, knowledge distribution, fewer distractions, faster learning. Limits: tiring, not necessary for every task (routine, research), differences in pace and knowledge. Use it for tricky spots, onboarding and important architecture decisions.

Collaborating well

Be respectful, let others finish, ask instead of correcting (“What if …?”), take breaks, agree on style and tools. The less experienced should not just watch: they should drive too. With a trainer or colleague it also works as mentoring.

See also: Code review, Agile methods (Scrum, Kanban), Clean code, Learning how to learn