Pair or Mob Programing

Mob and Pair programming are great techniques to improve the quality and stability of the code you produce. Programming with extra sets of eyeballs creates three main competitive advantages.

1. Both implicit and explicit knowledge is transferred between team members. New skills and team standards can be learned quicker than if studied independently.
2. Sticky or tough issues get resolved more quickly, as answers come from unexpected places.
3. Bad architecture will be spotted and cleaned up sooner because of the multiple perspectives looking at the code as it is created.

The most important aspect of Mob programming is the way the team learns from each other, gets exposed to new ways of solving problems, and exposed to more parts of the system than they would otherwise engage in.

The continuous code review to spot “problems” is the least beneficial aspect. This is because the real value in code reviews is in maintaining consistency across the project.

When pairing or mobbing, that learning and enforced consistency becomes essential to maintaining the flow of the programming experience.

Many people fear that they would hate to work with multiple people when they are so used to working alone, and to those people I suggest validating your assumptions before coming to a firm conclusion.

How does this apply to me as a developer?

• Always mob/pair when you can. You want to avoid dead time by waiting for code reviews. Instead, advocate for code reviews during the pairing.
• During the pairing, you will talk about what you are doing, how you are doing it, and why you are doing it. By reviewing the code during the session, you also review the plan.