What is going right: Mob Programming Benefits (Part 4)

I have been so busy with the teaching job that I have not had time to dedicate to this blog. Hopefully the teaching gets easier and cools down soon. It should now that the semester is just about done and there is not too much left in lesson plan prep.

But enough about me, here is What is going right: Mob Programming Benefits (Part 4). I will give a short explanation on the two benefits below highlighting the great parts of Mob Programming. Check out the other parts of the series for even more benefits of mob programming and expect more posts in the future.

  • Divide and Conquer
  • Accountability

Divide and Conquer

I am on a small three person mob working with a technology that none of us have had prior experience in outside of our current project. This means we run into situations that no one knows the answer to. How do we solve these complex problems? Well rather than squander around the code all together often we take a Divide and Conquer approach.

By divide and conquer, I mean that we will all split up and begin researching/attempting solutions/poking around the code all on our own. This may sound a lot more like traditional programming where everyone is by themselves working through problems and it kind of is.

The mob programming aspect comes into play whenever anyone finds a good example/article/forum post related to our issue. We share the findings and discuss them together immediately. Maybe the new knowledge helps connect the dots with what someone else was already reading or thinking about. Maybe the team decides that it does not relate, so we do not waste anymore time looking at it.

We take a divide and conquer approach but share all the knowledge along the way and get more research done while still keeping everyone informed.


In software, it can be easy to take the easy path instead of the harder but infinitely better path. When writing software you may think “Oh this will not be my problem in the future” or “I don’t need to test this feature it will never break”.

In my mob we hold each other accountable and ensure that we are not skimping just to make things easier for ourselves. I will relate this to testing because its an easy target. We test EVERYTHING. No matter how small we make sure to right a test first. Sometimes one of use will get an inkling that maybe we can skip the test on this one. Or we just straight up forget to write the test.

Having the mob, we always have someone to reign us all back in and remind us of the software practices we need in order to maintain quality. As a mob we are all accountable for one another and we use this to ensure we are always writing the best software.

That concludes What is Going Right: Mob Programming Benefits (Part 3), check out the other posts in the series.

What is going right: Mob Programming (Part 3)

What is going right: Mob Programming (Part 2)

What is going right: Mob Programming (Part 1)

What is going right: Mob Programming Benefits (Part 3)

Here is What is going right: Mob Programming Benefits (Part 3). I will give a short explanation on the two benefits below. Check out the other parts of the series for even more benefits of mob programming.

  1. Temporarily joining another mob
  2. Redundant knowledge

Temporarily joining another mob

Yesterday I found myself alone at my mobbing station. We are not allowed to write production software without at least one other person mobbing with us. So, I rolled my chair over to the closest mob got my name in the rotation and began mobbing with them.

The mob I joined was in a language I have very little experience with and a technology stack I have even less experience with. But I was able to follow along and contributed what I could.

I was mob programming with the team for roughly 45 minutes before we broke out for lunch. During this time I was absorbed into the new mob. It was an easy transition into the other mob. It did not cause disruption in the flow of the mob. And I got to learn more about the technology our teams are using.

Mob programming let me join an entirely different team and share my skills even if just for a short period of time.

Redundant Knowledge

When you have a group of 3 or more people all working on the same project at the same time together knowledge is going to be spread. Mob programming reduces knowledge silos essentially to zero. If someone is already very knowledgeable on a subject while the rest are not, the knowledgeable member navigates the others so the knowledge can be shared. Knowledge silos do not last long if they exist at all.

A second major benefit of redundant knowledge is that members can leave. For something as common as getting coffee or water, when a member leaves, the code is still moving forward. And even more importantly if a member goes on vacation all the code keeps on going. We do not run into roadblocks because of the redundant knowledge.

Redundant knowledge means 100% participation by every member of the mob at all times is not necessary. People can come and go as they please without worry.


That concludes What is Going Right: Mob Programming Benefits (Part 3), check out the other posts in the series

What is going right: Mob Programming (Part 2)

What is going right: Mob Programming (Part 1)

What is going right: Mob Programming Benefits (Part 2)

I have been in the mob for over a year and have more aspects of mob programming that I would like to share. Let’s jump right into What is going right: Mob Programming Benefits (Part 2).

  1. Idea Generation & Development
  2. Efficient use of time

Idea Generation & Development

Mob programming promotes the generation and development of ideas. You have multiple team members to bounce your ideas off of in order to come up the best solution. You do not need to come up with entire solutions on your own or have a fully thought out idea.

I have found myself presenting a half-baked idea, knowing that with the help of my team members we can work the idea into something real. It is a great feeling to be able to present just half of an idea and get input from the team on how to build it out to fruition.

This also helps in the opposite direction. If I present an idea not fully thought out and a team member can point out the flaws; I do not have to waste any more time trying to build the idea when in the end it would not even work anyway.

It is hard trying to take an abstract concept in your head and code it up into a full solution all on your own. But with mob programming, you have the help of your team the whole way.

Efficient Use of Time

Mob programming makes efficient use of the developers time. My mob only has one, yes ONE, regularly scheduled meeting a week. And even better only one mob member has to attend so the three of us on my mob rotate. I go to one regularly scheduled meeting every 3 weeks.

The rest of my time is spent coding. If my mob decides we should discuss a topic more in depth before jumping into code we do not schedule a meeting and find a conference room away from our computer to discuss.  We simply swivel our chairs to the whiteboard or just start talking.

On a good mob, impromptu discussion just happens when it needs to. If the code is flowing fast then no need to discuss, if we are up against a challenge start discussing.

Mob programming lets you focus on the code, which is exactly what every developer wants to do!


Stay tuned for more What is going right: Mob Programming posts. If you have not read part 1 check it out here What is going right: Mob Programming (Part 1)

Mob Programming: Moving from a Multi-Mob Project to a Single Mob Project and the Sense of Accomplishment

I just hit my one year anniversary at my organization as a mob programming software engineer. I wanted to share one of the experiences I have had over the course of that year.

My first 9 months at Hunter I worked with the same team. The team consisted of eight developers. This team generally had two mobs going. So, I would be switching mobs on roughly a weekly basis. This meant I was changing tasks being worked on and not always seeing tasks to completion since I would switch to the second mob. This all sounds great sharing knowledge and changing mobs being worked with.

The big change came in February. I changed projects. I moved to a team of just three developers including me, so a much smaller team. With just three developers this means we are a single mob all the time, every day. The biggest difference is no more switching between mobs, no more switching between tasks. I am seeing all our tasks from start to finish. It might seem difficult to work with the same two other people every day but honestly, they are great!

This no more switching of mobs, no more switching of tasks has led me to have a much greater sense of accomplishment when it comes to programming. Something I have heard from more than one developer has been their feelings of lack of accomplishment. They think they are just a tiny piece of a much larger project. Or simply the fact that they cannot physically see or hold their project makes them feel less accomplished. Putting your code on a flash drive and waving it around saying, “look at what I made”, is not all that fulfilling.

The fact that all three of us on the team work together always, all three of us complete tasks to the end together, and all three of us struggle through the hard problems makes for a strong accomplished team.

Numerous times while working on my old team of eight, one mob would be struggling on a challenging problem while the other was working on a different problem less challenging. One mob would be having a bad day trudging through a problem while the other was moving forward at a normal pace. The pain was not always shared but due to having two mobs it could not be shared, that is just how it was.

Now, it is never fun to have painful programming days but at least if the whole team shares the pain it can be more of a team building experience rather than team dividing. When a problem is solved by the whole team together a greater sense of ability is shared and most importantly if the same problem comes up again later we can crush it!

I mentioned above the task switching problem and that was a major hindrance to the feeling of accomplishment. At times, I would be working on a problem all week and just when we were about to get to the light at the end of the tunnel I would switch mobs. I felt almost robbed of the accomplishment. I know I was a major player in the completion of the task, but damn, it hurt just a little to be taken away before seeing it to the end.

Do not get me wrong, one of the strongest points of mob programming is the switching of mobs within a team to ensure no knowledge silos are formed. But it is important to see the other impacts that switching teams has. I felt somewhat cheated of getting to complete something I had worked a long time on, but also I felt I lost some learning because I did not get to participate in the final steps to solving the problem.

Overall on my new smaller team, I feel more accomplished. I am seeing all our tasks to completion, I am struggling through the difficult parts altogether as a team, and I get the fullest sense of learning because I was not taken away at any point from the problem. Again, I had plenty of feelings of accomplishment and achievement while on the larger mob, but now I get to experience every accomplishment and achievement with the smaller team.

Expect more post and experience reports about switching from a large mob to small.