When I started working, I was eager to learn new things. I envied senior developers and what they were able to accomplish. I wished I could watch them work, see how they performed. Sure I could read their work, but that would not teach me how they got there, only that their solution was complicated at first then made sense, only to realize that if I were to have the same task, I would not be able to get there.
As a child, I would ask my mother to teach me how to make her crèpes. She does it all by heart without any measuring at all. It's frustrating to see her do but not have any way to reproduce her recipe. Learning comes from practice. It's ancient knowledge. Still, we need to remember it and apply it wherever necessary... crèpes or code!
By the way, before learning my mom's recipe, I've found a great recipe that came along with my crèpe pan, so no need to try and learn the impossible.
Coding is no different. Programming with more senior developers helped me learn a great deal. Though I regret that those moments were too scarce as two developers were working on the same thing. Worse than that I was taking precious time off of a senior developer, wait until management finds out!
Years passed and I built my own experience out of reading a lot of articles and code. Then came pair programming. I tried it out in a few meetups on some code katas. Loved the concept and decided to bring it to the office. Didn't really tell management as I thought they wouldn't see the point in all of that. It went really well and here are the following benefits I noted :
- mutual learning of techniques; things that have nothing to do with the business, but made our daily lives a lot easier.
- better comprehension of the domain
- spotting bugs early
- better code design
- no more need for code review
- no more need for sharing details about the work done as we both had the same amount of knowledge
- going faster, not twice as fast, but with more confidence
- in the end, a lot fewer bugs
- better communication in the team
- team building and fun
On the other hand, pair-programming can truly be exhausting if it is practiced over a long period of time. Some recommend using the Pomodoro Technique in order to have small resting periods.
Personally, I've had some difficulty cutting down on time. During pair programming, the added speed and confidence can be exhilarating. My advice on this would be that if everything is going well, stop at a significant point. Completing a full feature would be a nice time to stop. Or if something just doesn't seem to work, then stop, give it some time, sleep on it and you'll probably end up with a solution the next day. You'll be surprised how simple it could have been and how that last hour of teeth-grinding just wasn't worth getting out of work early.
Pair programming has real advantages. On my current project, management was reluctant at first, but since I was with a junior developer and that he was having trouble, I decided to work hand in hand and teach what I could. Progress was amazing. So much that he became more efficient than another more senior developer.
This is when I decided to take pair programming to the next level: mob programming. This was not an easy task as we are four developers on two different locations. Fortunately, we have screen sharing techniques with a corporate Skype, proper headphones with a decent microphone. So instead of being two for programming, we were four. It turns out that the benefits of pair programming were accentuated. As a team, the major benefits are the following.
- Shared coding style
- Instant code review
- Very few bugs
- Better software design. A middling software design would have passed code review, so mob programming was our chance to have a better design in the end.
- A better understanding of the code we worked on
- No fuss about working alone on this code. Some features were not taken on by some in the team due to lack of knowledge of the code
Of course, mob programming means that four people (in this case) are working on the same thing. As far as resource management goes, it does not seem like a good idea and that it is not as profitable as having four developers working independently. I can adhere to that perspective.
Mob programming's best advantage is that it considerably cuts out on the bus factor. Team members are more eager to work on new parts as they know they will be accompanied by someone who knows. And if not, it's better to go into the unknown code with someone else willing to understand. By reducing knowledge bottlenecks, we are not only reducing risk due to the bus factor, but we are also smoothing out flow (hello FlowCon). Indeed, time-to-market is not merely affected by task completion time as it is by task wait. Instead of waiting for the only person who can complete the task because he is not there, sometimes for an indefinite amount of time, we have the opportunity to limit pressure on a sole person so as to minimize wait time.
Mob programming should also be used to kick-off a new complex part of the system, so as to have everybody agree on the solution and not just be contempt of someone else' solution. It is also a great on-boarding tool as it provides cohesion and shares team practices.
Nothing is more important than getting experience from the field. A degree is only a preparation for the real learning which takes place during an everyday job. Learning can happen alone, but to really gain experience, especially on a project, pairing is a real booster. Gathering with teammates will not only spread knowledge but will encourage quality. A subtle measure has to be found as to when to pair/mob and when to work alone.
NB: After writing this article, I read Ellène Siber-Dijoux's excellent article on pair-programming (in French). Needless to say, I fully agree with her and she probably said much of what I said here in a simpler and clearer way.