The Last Unicorn Developer | Pairing and Mobbing

Teams delivering outcomes is the only true measure of success. Pair and mob programming can drive teams closer to this.

I don’t believe in unicorn

We’ve all heard of the Unicorn Developer. It has various names across different regions and companies such as the Hero Developer. But we all can identify who they are when we see them. For those who don’t know; the Unicorn Dev is the one who has all the knowledge. They’re the person who writes the most magnificent code, which is usually the least understood. They have all the keys and secrets in their head including all the ideas and knowledge. They are often the one producing so much new work they don’t have time to document it meaning no one else can continue on the work in there absence. At this point you can probably identify who the Unicorn is on your project. It was Brent in the Phoenix Project; it could even be you where you’re currently working!

So why do I have a problem with the Unicorn? The Unicorn is a bottleneck and an icon of failed projects. They are the single point of failure in the system. When the Unicorn goes on holidays, projects grind to a halt. When things go wrong, the Unicorn has to step in to fix things, meaning new work cannot be completed while they are preoccupied.

I’d prefer a horse drawn carriage

My role requires me to help customers to be self sufficient and create high performing teams around products. One of my key philosophies in achieving this is “Mob to learn, Pair to build”. I always build this motto into the teams Social Contract. Pairs and mobs allow for knowledge transfer and create shared understanding of the problem and the journey to the get to the solution. Just like a horse drawn carriage, groups of two horses in sync with each other driving the carriage to it’s destination.

Pairing and mobbing

Pair and mob programming is brilliant way to achieve shared understanding and drive up code quality.

To understand why pairing different let’s use an analogy. Imagine you’re a carpenter and you look at a magnificent rocking chair. What do you learn from seeing the completed piece? Probably not a lot, you might see how one or two pieces connect but not all. Now imagine you worked with the carpenter assembling and crafting the pieces. You’d get to experience the hidden parts, the joinery that was used, how it was created and how it’s all connected. You’d identify the problems faced while fitting the parts together and understand why they’re assembled in a given order. You could take a step back and review the furniture as it’s being built giving you a better perspective on the creation process. The same applies in writing software engineering. Pairing makes better programmers.

There are a number of interesting advantages to pair programming (and mobbing).

• Mentoring of team members. New team members can be brought up to speed quickly when they work along side, tackling the same problem as someone who knows the code better. Sharing tips and tricks or shortcuts can widen both pairs skill depth. This sharing will bring can also bring junior associates up to speed very rapidly.
• Half the code. When you ask an organisation to spend two developers on one problem the usual maths kicks in of “won’t that mean half the code gets written?”. In truth; hopefully even less code gets written! Two minds working on the same problem makes for more efficiently written code so less spaghetti.
• No pull requests. Pairing means you have to share your thought process with your pair. This synchronisation means code is being reviewed as it’s written. Often people reviewing pull requests are too busy writing their own code they can only give very superficial reviews. When you pair, you review as you go and therefore write leaner more understood code. You won’t cut corners when pairing as someone is watching
• Team bonding. Humans are social creatures, we share and interact all the time. Pairing and mobbing facilitates this interaction. Instead of sitting in a room with headphones in, ignoring the world around, developers in pairs look happier. A room with mobbing and pairing going on is louder. Happy coders leads to better code.
• The knowledge stays in the team. With more than one mind solving the same problem, the understanding and logic stays with them. As pairs naturally shuffle from task to task the depth of knowledge stays with the team and not with an individual. This means when holidays or even flu season take over the team can still continue to work at pace knowing the Unicorn is not leaving with key information

My motto “mob to learn; pair to build”

When tackling new problems with teams, whether that’s a new framework, language or even a particularly hard problem we all group together. Huddled around one computer and a very large screen we explore. We mob around the problem set until the group is satisfied we have enough knowledge or have a rough scaffold of how to complete our tasks. The team then breaks away into groups of two to pull items from our backlog and begin implementation.

Mobbing and pairing allows teams to cross skill. Sharing experience and expertise leads to better teams. Well oiled teams working like this can continue to build their product sustainably and at pace driving towards outcomes not outputs. I would never mandate pairing but would 100% recommend it for building high performing teams. Having worked almost exclusively in pairs over the past year, I struggle to see why I would work any other way.