Solo programming vs Pair programming vs Mob programming


Programming is viewed as a job for individuals. Especially by the people who are not in the IT industry. But in reality that is often not the case. Developers collaborate together to solve problems, to get new ideas, to get different perspective… And from that ideas of pair programming and mob programming are born and added to more mainstream solo programming.

All of these ways of programming have their pros and cons.


Solo programming is probably the most popular way of doing things. It’s often the most easiest way logistically speaking and people feel like they can do their best work when they work alone. They can work at their own pace, they can develop their own solutions, try new things and solutions. And since all people are different, and they have unique ways of focusing on work and developing a solution, solo programming allows them to do just that. People also sometimes feel pressure when there is someone constantly looking over their shoulders while they do their work, which can cause them to work slower, lose focus, feel embarrassed when they don’t get the right solutions, or something is not working correctly, which is way for those people solo programming is the way to go. On the other hand, some people are not comfortable with asking for help when they get stuck on a certain problem. For those people, the next way of programming can be very beneficial.


Pair programming is a way of developing software in which two developers work together on one machine to develop a piece of software. This way of working promotes collaboration from the very start. Two developers are “forced” to work together, to talk to each other in order to finish their job. When doing the pair programming, one developer will write code while the other will observes and reviews that code. This can sometimes increase the number of hours that are required to finish a task, since only one person is writing code, but, if done correctly, result can be a code that is better and has fewer bugs, which will in return cut down on the amount of time needed to go back, review, change the code and fix it, once the testing is done.

Two heads are better than one seems like the main motto of pair programming. Two different ideas, two different ways of tackling a problem seems like always a good idea. But sometimes it can be detrimental to the task in hand. When choosing the people who are going to work together it is important to try and put together people who are compatible. If two people have interpersonal issues they should not work together in pair programming, since that can cause them to do the job poorly.


Mob programming is way of programming where, unlike with pair programming where two people work together, entire team comes together, to work on the same problem, on the same machine, in the same room. Mob programming can also work with other parts of creating a software, such as creating user stories, requirements, testing, design, meetings… Using mob programming is expected to solve some problems that might otherwise occur. Communication problems, not responding to emails quickly enough is easily solved by having face-to-face communication. Even more eyes on a problem than with pair programming means that code will be even better reviewed. When more people work on one problem, more solutions can be found, and they can be found easier.

Mob programming is sometimes necessary, as sometimes it is required from everybody to give their input and opinion, but other times it can cause some problems.
For some people this way of working is not appealing, which can cause disruptions inside the team. And in these days, when we are facing contagious disease, mob programming can increase the risk of spreading it.

Which is way, today is solo programming maybe the best option, since the effectiveness of virtual pair programming and mob programming might not be the same.