Pair Programming, Mob programming or none of the above?

I want to start by saying that I enjoy pair programming. I’ll try to do my best to be as objective as I can, but I wanted to let out this fact, from the beginning.

Pair Programming is a fancy way of saying that 2 developers work on the same task, on the same computer, while mob programming is the idea of the entire team, working on the same task on the same computer. Mobbing is the ex peer programming, in which more people are paired on the same task, so, in my mind is just another term for the same thing (but I guess people think it sounds more “cool”).

Pair programming appeared first in the Extreme programming methodology and it was meant to improve the quality of the software and get releases (or feedback in general) more frequent vs the other Agile methodologies. Mobbing appeared in the 2000s and for some reason lately more or more people find it “cool” (yeah, I know, around 20 years later).

Now, since you have an idea about what both of them are, let’s dive more deeply.
If you think both are the same, well, you’re wrong, and hopefully, by the end of the article, you’ll get why.

Since now you have an idea, of what both are, let’s see how you can start, but first I want to tell you from the beginning that if you stay on your phone playing candy crush, or if you read your emails while the other “player” writes the code, oh well, that’s not pair programming, that’s only one of you being lazy and the other becoming frustrated.

Step 1

You and person X (who is your partner in crime) are taking a task. Before starting to code and jumping into details you need to have a common understanding of what you need to do. The first step is to create a list of questions and make some research. The questions should be basically how to implement in a way and why is that the best solution. Get a timebox for finding the answers and after that stop the call, both go on their computers and start researching. From my experience, both staying on only one computer and searching on google for the answers to the questions is a pretty inefficient way of solving this part. I like to do this research part on my phone, but I saw that while I was in the office and paired, my “person X” thought I wasn’t paying attention anymore, lost interest or got frustrated, so I started to use the laptop for this also.

Step 2

Come back on the same computer, present both the answers you found and see which “path” you want to take. You shouldn’t be surprised if, after a while, the timebox will be shorter and shorter, and the answers will be more or less identical. This is something normal for a team that got more “mature”, and the team members got to know each other.

You can also call those 2 steps the planning phase since you both need a common understanding of what is the problem that you need to solve, what will be the best solution and what will be the approach that you’ll take to implement the “fix”.

Step 3

Chose a pair programming style and start working.
If you don’t have any experience with pair programming styles, continue reading, but if you do, you can jump to step 4

Unstructured Pairing
You can imagine yourself as a fireman. You create for yourself time slots, for example for 3 hours and just jump from task to task, pairing with the “owner” of the task and helping him solve it faster (or at least get the knowledge of why and how he is solving the problem with which he is dealing with, because, without a problem, there is no task). This technique is nice, but after some days, it becomes pretty exhausting for the “fireman”.

Driver — Navigator
For some reason, I think this style is the most used worldwide. The navigator should focus on the bigger picture and the driver is the one on the keyboard, typing the code and taking the decisions on a smaller scale level. You can imagine the navigator, looking at how to split between layers of the implementation, checking that everything is accordingly to the agreed architecture, trying to find potential issues and being sure that they both stick to the agreed plan from the previous steps, while the driver writes the code and takes the decisions like if he wants or not to create a facade, which piece of code to extract or not in a private method and so on.
PAY ATTENTION: As a navigator, you can suggest to the driver where to move some pieces of code, or how he should name a method if he needs/asks for help, but do not bother him the entire implementation. A common rule is to wait for 5–10 seconds until you talk, or let him write 10 lines until you provide another opinion. Let your driver make mistakes and give him the chance to correct them. Do not become a stress for him.

Backseat navigator
This works only when an expert pairs with a junior; in any other case, the navigator is just a stress for the other person. This style is pretty much the same as the driver-navigator style, but here, the navigator gets his “hands dirty” way more; he should suggest in more detail what the driver needs to do, how he should do the implementation, maybe even write to the driver the steps he needs to do to implement the solution. His role here is to teach and explain to the driver each step of the agreed implementation.

Tour guide
This looks like the “backseat navigator”, but, this is working very good in two situations:

• If one just came back from vacation and doesn’t know what’s going on. He can be the driver, while the navigator explains to him what needed to be done and how.
• In the onboarding process. The new guy writes the code that is being explained by the navigator — the person with more experience on the project.

Ping — Pong
This is a style that is used usually in TDD. The first person writes a test and gives the keyboard to the second person who is creating the logic to make the test pass, refactor, writes the next test and gives back the keyboard.

My advice is to try out all the styles until you understand which style you like the most and fits your needs and it’s important not to be rigid. You should choose the style together with your partner.

Step 4

Announce on the group chat that you finished the task, update the board, and wait for someone to do the code review. I think that if you paired with someone on a task, only one reviewer is enough since there were already 4 eyes on that piece of code. After this moment, you can start working on another topic, but I would suggest pairing with someone else if you’ll start working on another implementation task.

If you are using mob programming, this step is ignored, since the entire team worked on the same thing, so no code review is needed. Some of the mob programming lovers say that this is helping everyone to get faster feedback/to get tasks into testing/done faster, but in the long term, I consider this more exhausting, people lose their interest faster if more than 3 people are involved is hard to keep everyone focused and on this remote programming era, I don’t think this is the way to go.
In my mind, if you have a mature team, the code review should be done pretty fast. Let’s say take an example:

You have a team of 5 devs. You just finished Task K, put it into Code review, it’s pretty normal that you or mister X will start reviewing task D and the other person that is free between you two, will try to pair on task C. It’s common sense that you should do your best to push the tasks to the right. The rule says to look over the board and take the tasks from right to left and from top to bottom. The first person that will finish (or take a break from) C, G, or H, will code review K since it’s the most important and since you or mister X are already working on D.
If you are saying that people get focused and they don’t look over the chats or board, let me give you another piece of advice that worked for me: I split my day into 3 parts: when I open the laptop, after the lunch break, one hour before shutting down (or right before the last break that I take before shutting down). Those are the 3 moments in time when I can pause my current task, I am not focused on it as I was before and I can do something else without losing much time with the context switching. In conclusion, it will take for someone to wait for me to do a code review, or a pair for a maximum time of 4 hours. I don’t think that’s the biggest time loss in the lifetime of a story.

Some advice:
We live in a world in which most of us work from home.
1. Make sure you have a good connection
2. Always keep your webcam on
3. If you need to read an email, answer the doorbell, answer your phone, announce your partner about this. Do not ignore him, do not make him feel alone. It will just create frustration and both mob programming and pair programming are meant to be enjoyed by everyone.
4. Even if you see that something is wrong, don’t be impatient. Give a chance to your partner to see the mistake.
5. Do not drift apart and keep yourself focused on solving the issue.
6. Do not dictate what your partner needs to do/write.
7. Do not pair for the entire day, with the same partner on the same task. It will eat your energy and you won’t be focused for the entire time.
8. Do not keep the keyboard for yourself. Any style you are using, rotate the roles after some time. I suggest trying the Pomodoro technique. This means setting a timer to 25 min, working, taking a break of 5–10 min, and then changing the roles. After 3–4 “Pomodoro” sets take a longer break for 20–30 min.
9. Always, at the end of the sessions, take a break and talk about something else. Get to know each other and clear your mind of the task. This will help you change the context for the next thing you’ll have to do.
10. While paring junior with experts some frustrations (because of the lack of knowledge) might appear that need to be eliminated.

Benefits for both

• Knowledge share (and faster rump up)
• Keeping people focused (You can’t be distracted if someone else is looking on your monitor, or waiting for you to help him)
• Code review on the fly. There are already at least 4 eyes that saw that code and think it’s the best solution
• You won’t have the problem with only one person having the entire knowledge of something, so the team won’t be dependent on a single person.
• Keeps the work in progress low

What I don’t like about mobbing is that the entire team is blocked for one task. If it’s a hard one, maybe it’s fine, but even then, I wouldn’t keep the entire team focused only on one thing until it’s done. I think it’s counterproductive and hard, since we almost all, work with people that are in different time zones. Getting 2–3 people tops on the same call is ok, sometimes hard, but can be done. Getting 5 people in the same call and being focused, is way harder. If you need to keep them there for 3 hours might be pretty stressful for everyone. For fun, it’s nice to do it. You can get an action item on your retrospective, to get in the next sprint 4 hours for mobbing on a story. I can agree with that. And if you want to make it more fun, you should use a tool like moobster, to have the timer, roles and so on and you can switch places after 10 min. It’s pretty intense if you’re doing it right, but in a big team, some people might get bored, if they are not involved. Just think about the roles: one is the navigator, one is the driver, one can search different things on google on how to do some improvements, another one can look at another part of the app but from the same story/task an add on a ToDo/Improvements list, things that they should look over, on the next round, but, that’s the maximum you can get.

Not to do either, is bad. You need to have fun, learn from each other and be a real team. This is one of the first steps. This way you gain confidence in your team and the team in you. It doesn’t matter if you are a TL, an expert or a junior. Don’t tell me that Google or Facebook is not doing either of them, I don’t think this is what we should learn from them.

I don’t want at the end of this article to think that everyone is against you, if they don’t want to pair with you, or if you “don’t get time to do it”. Most business people think that if you are pairing, the coding will be slower. There are a lot of developers that actually are way slower when someone is watching them, or just prefer to work alone (lonely wolfs). There are also cases in which the two partners are just, incompatible. They have too different “working styles”, so you can’t force everyone to pair with you.

If you are a manager you might think that you pay 4–5 people to do the job of one. You are wrong! You pay for a product, you pay to get something done, and you are paying a team, not individual people. As long as they deliver what they committed, why should you care how they doing it or who is writing the code? (And a piece of advice: you should almost always go for quality over quantity and this can’t be done only by one dev even if he is an expert on what he’s doing. You can’t see all the corner cases, but an entire team can do it. If you think those corner cases will be caught in the code review or by the testers, well…maybe, but how much time until then? You should fail fast, to be able to recover even faster). And again, even if you are paying 4–5 people, it’s not like everyone will look on someone else’s computer and that’s it. They will try to improve the code, come up with ideas for the best solution, knowledge share and so on. In practice, I found it very helpful in algorithms or random pieces of code that took me more than 2–3 hours to figure out how to do them. In my mind if you get stuck for more than 2–3 hours on something you must pair with someone to help you out, change your perspective and so on (basically ask for help); If in another 2 hours you both still didn’t see the way out, you should go for mobbing since for sure, this is something worth sharing and finding the solution as a team will bring a great benefit for everyone.

In my opinion, the benefits are clear, so even if it’s hard in the beginning everyone should try pair programming, but like everything in this programming world, you shouldn’t do it for everything. You shouldn’t pair absolutely for any task. Keep a balance as you do in everything related to your job.