The setup

In all the time that I have been programming, all the different companies and projects, there has been only a very specific type of work that I never thought that pair programming was needed. And that is because they were single day jobs, in which we were using a framework to get a small app to process some input data and get some output in PS, for printers. Think about the letters sent to you by TFL, or Legal & General, or some other company that needed to do some transactional mailing. Of course, we also had bigger projects that will be changed slightly every quarter or half year or year. At times they were a textbook example of why you really wanted to optimize for reading/comprehension, due to the high chances that different people would be working on each project completely on their own.

But other than the specific subset I described above, there has been no case in which I thought that being alone was better, or could have been better. Coding is design (micro and macro). And as such, it benefits greatly from having more that one person discussing and talking about it.

There is a lot written about pair programming, so if you want to read a bit more about it you can go here or here for more information, to put a couple of examples.

The efficient and effective method

My experience has shown me that pair programming is both more efficient and effective than working solo with Code Reviews or PRs. So, whenever someone says they don’t want to do it, what I hear is that they don’t want to be neither effective nor efficient. Which is something that rubs me the wrong way. And at the same time not completely fair, especially if I don’t know the experience of the person. But if you go with senior on your title (for another time, the fact that we are calling people senior that don’t have enough knowledge), I believe you should have read about it and practiced it and, maybe, you have good reasons to disagree with me.

The same happens with other practices and techniques that I have found that produce better outcomes. If I am doing something that I have never done before (game programming, or OS development, to put a couple of examples), then maybe those techniques aren’t that great, I would need to give a try for a while to understand their suitability. But what has been my bread and butter for the last few years (backend web systems, especially APIs in multiple styles/formats) then I know that they work and they work better than the different alternatives that I have tried. To move away from that, someone has to show some strong evidence. Or if is a new technique/approach that I haven’t used … I am actually happy to give it a try: what is good now doesn’t mean is the best thing forever (after all, our field is relatively young).

The complains

Other than people thinking that two people coding on separate tasks is quicker than two on the same task, because they have the wrong mental model about what coding is, there are two complains that I have heard a lot: I like to solve/fix issues on my own and is tiring (this especially paired with videocalls).

For the former there is a straight answer: this is not about your ego, this is about the work that you do for the company. If you want to stroke your own ego, that is what hobby programming is for. I like flexibility at work (it favours thinking), but there are always limits, based on the needs of the company. This is definitely one of those cases in which the needs of the company are bigger.

For the later … develop your stamina. Chess isn’t an exerting physical game, is it? But, have you ever heard of the routine of chess Grandmaster when they are playing professionally? Fabiano Caruana’s routine (current number 6 in the FIDE ranking) has him doing running, basketball and swimming every day. They do physical exercise to increase their stamina levels. Mental work is still work. Still tiring (another reason to keep your work hours limited, 100 hours a week constantly ends producing worse results than keeping it at 40).

At the beginning of my career, even working on my own, would tire me. That doesn’t happen any longer because now I have the endurance. Pair programming, without good control (pomodoros, for example) is a technique that doesn’t give pause to your head, it can become quite intense. Pair programming is demanding as you start working with it. But, again, your stamina increases the more you practice it.

The technique to use

Maybe I am wrong, maybe pair programming is not what I should be doing. Maybe the above is why ensemble programming is a better discipline than pair programming, as it solves some of the issues that I can see with Pair Programming (intensity, scheduling, …). It could lead to more cases of people switching off completely, but then that is unprofessional behaviour. The tiny bit I have seen of Ensemble/Mob programming seems to work very well, and a few people of whom I pay attention to their opinions talk highly of it.

I am going to need to practice it more.