Mobbing, as a sociological term, means bullying of an individual by a group, in any context, such as a family, peer group, school, workplace, neighbourhood, community or online – Wikipedia
Mob programming on the other hands has a positive outlook as it involves minimum of 3 engineers on one computer, getting together to solve a programming problem.
A group of engineers basically (mostly co-located) grabs a room and allow one person to drive the application development while the others watch on and pitch in.
I had practiced Mob programming with my former team, but we used to do it once in a while especially when we all are trying to learn a new language collectively, but I recently joined a new team whose day-to-day practice is Mob programming.
I was used to picking my own stories from the board’s Todo and try to solve the problems, performing pair programming with other members of teams, but this is another level of pair programming, especially, if you are not the one driving, it could be a little boring especially if you do not have a clue what the team is trying to achieve.
After a couple of weeks with the team practicing Mob programming, I finally got comfortable practicing it and I try as much as possible to drive too.
Here are some of the useful things I learnt practicing Mob Programming with my team mates:
Engineers Get stuck less
Mob Programming makes it easy for other developers to pitch in their ideas during the session, instead of one developer rack his/her brain trying to solve a specific problem, there is always going to be another person in the room with a fresh idea on how to go about solving the problem, hence, problems are solved faster together.
Different Engineers have different approach to solving different problems, but when you are in a mob session, you always go for the best engineering approach of solving problems, most of the times, engineers just want to get it working first and refactor later, but with mobbing, the refactoring is done on the spot and better engineering approaches in terms of performance, cleaner codes etc., are mostly attained.
Teams that practice Mob programming more comfortable sharing personal information with one another as they tend to talk and bond regularly. This improve performance among the team.
The more a team work together rather than in silos the more trust they build among one another and the faster they are able to deliver and ship excellent codes to production. There are less tension and friction within the team when you practice mobbing, since over time, you have grown accustomed with each other’s behaviors, dos, don’ts. Each member of the team would know when not to crack jokes and when to throw in some banters into discussions with another members.
The traditional approach to software development is mostly one person solves a problem and create a pull request for other team mate to review, see the code in another dimension, put comments and reject or accept the request based on his/her satisfaction of the code, but when you practice mobbing, the code had already been reviewed since all of you agreed to solve that problem in that specific way.
A lot of the times, a lot of engineers are more comfortable solving problems while no one is watching, they probably think better alone, but with Mobbing, everyone is watching what you are trying to achieve which increases pressure in a way. Over time, engineers grow more confident sharing their screens to the rest of engineers while solving problems and thus, become more proficient in not just coding ability but also leading a session.
Like any other programming practices, Mob Programming has its cons, but in my little time practicing it with my team mates, I find it very useful for both the engineers as well as the companies they work for, as they are able to become better engineers themselves and are able to deliver and ship codes faster. Everyone wins!