Pair and Mob Programming: Best Practices

We've all heard of pair programming, that concept where two or more programmers work together on a solution. The term "pair programming" evokes a lot of reactions when you first broach the subject with developers. Hopefully, this article can help put some of the negative connotations around pair programming to rest.

Pair Programming

So, what does effective pair programming look like?
Pair Programming consists of 2 programmers where one is a navigator and one is a driver. This pair works together on one story at a time, where one programmer is a navigator and the other is the driver.

Mob Programming

Mobbing is similar to pairing, except that there is one driver and many navigators. In mob programming, everyone works on one story while one person drives and everyone else navigates. Mob programming is best used when only one person has experience in something and needs to catch the team up, or when the team is learning something new together. Otherwise, pair programming is a better approach.

Roles

There are two roles, as you've no doubt already noticed in pair and mob programming. These roles are the navigator and the driver. It is important that the people in these roles remember that they are a team and are working together to complete a task. We'll break down what these roles entail below.

Driver

The driver is the person who is at the keyboard, typing the solution. As the driver, you type what the navigator says and don't "run away". Running away is the term used for a driver who stops listening to their navigator and just starts typing their own solution. It can be hard not to do this as the driver. Sometimes because the navigator doesn't know what to do, sometimes because the navigator is going too fast and it's hard to keep up. This is where it's important to signal overwhelm. This can be done many ways, such as simply lifting your hands from the keyboard, simply saying "let's slow down" or any other signal agreed upon between navigators and drivers.

Navigator

As the navigator, it's your job to explain the solution and help your driver to code it. Navigator roles are best taken by the more experienced programmer per solution. As a navigator you want to make sure to find the level of your driver. Don't direct experienced programmers as if they are novices and don't direct novices as if they know (or should know) everything. It is also important to pay attention to cues from your driver. If you notice them feeling overwhelmed, then know that it's time to adjust your approach or take a break.

Timing Tradeoff

It can be hard to pay attention and stay focused during pairing and mobbing sessions. Working for too long can lead to fatigue. On the other side of this coin, sessions that are too short can lead to too much overhead while switching drivers. A few ways to remedy this are to take frequent breaks and/or switch roles as often as makes sense or when possible.

Breaks

Breaks are an incredibly important part of any work day, but they're especially important in pair and mob programming. It's not uncommon for team members to be used to staying at their desks all day, which can lead to them feeling guilty if they aren't actively programming. This is where it needs to be said that breaks are important. They keep everyone involved, allow time to absorb the current work and think about the solution. They leave room for new ideas to incubate and can prevent mental fatigue. Furthermore, pair and mob programming become less effective as team members lose focus.

Discussing Code

You might have read about the role of driver and thought to yourself, "so I just have to type what I'm told, no matter what"? The answer to that question is a solid no. If you had to blindly type everything the navigator told you to type then that completely erodes the concept of teamwork. While drivers and navigators will not always agree on the solution, it's important to be respectful and remember that everyone deserves to be heard. A good way to mediate this is to argue in code. Meaning that you can show brief examples in your code or on a white board to discuss the solution. This helps everyone to think through the problem at hand and come to an agreed upon solution.

Convincing your boss or your team

So, why should you use pair or mob programming? Pair programming helps prevent mistakes, gets work done faster, and leads to better design. It is also excellent for mentoring and onboarding new developers. It helps build communication skills and foster teamwork. Plus, it's often a lot of fun, but that one may be my personal opinion.

If you want more information on pair programming, I'm always happy to answer questions. I can be found at @DevCharissa on twitter. You can also watch my talk for Women Who Code DFW on youtube for a more in-depth version of this article.