Pair Programming: Use it, don't force it!

It's been a while since I've written so I am bound to be rustier so it may not be a bad idea after all to write about something I have a strong opinion of. This way, if no one agrees, I can at least blame it on a recent lack of writing experience :)

For those who don't exactly know what pair programming is, it is essentially a methodology where you essentially write code with another developer either sitting right next to you or watching you over a screen share. The basic premise as I understand it is that 2 minds are better than one. Of course, these are variations to this approach where the number of people working on a given task at any particular time could range from 2 to just about any number, and at that point, it becomes what is called mob programming. That's essentially the concept.

Just like with almost everything else in life, it is hard to conclude anything with a Yay, this works and is the best way to go or Nah, this is the worst idea ever. Most things in life make sense and work wonders for some people, some teams, some companies and some communities in some regions at some points of time. And as we all know, the devil is certainly in the details. So, with those disclaimers and with the assumption that we are more or less on the same page about this concept of pair programming or pairing, let's delve into the pros and cons of yet another new concept in programming.

I've always believed that a good engineer can solve complex engineering problems regardless of the tools available to them. They will find a way to make it work. You could constrain them with the most limiting of technology stacks but they will solve your problem and quite likely, to your utmost satisfaction. Unfortunately, the converse of these statements ends up being true as well.

Therefore, if you were lucky enough to hire a good engineer, half your problems should be solved already (if not more). Now, you just need to do your bit as an employer to keep them happy so they give you more than the bang for your buck. A happy employee is a very productive employee. As to what all it takes to keep employees happy, I have little clue. I have zero HR experience so I am not even going to attempt to get into the broader aspects of a very complex discussion. Rather, I am going to try and keep my focus on a single element that I want to call programming freedom in the context of pairing. What can you do as an employer to get the best out of the developer you hired?

What I like about pairing

• It promotes collaboration. You will be working with someone else most of your coding time.
• You get feedback real time. You don't need to wait for code review comments coming out of PRs.
• You learn continuously from your co-workers. You will learn more efficient ways of doing things (keyboard shortcuts to design patterns).
• You don't need to pre-define project dependencies. You don't need to wait on an API from your coworker. You write it with your coworker, and then you both implement the UI (as a simple example). A Project Manager doesn't need to manage dependencies.
• You will get to know your coworkers a lot more and a lot faster. You will pair with different engineers within and across teams so you will get to know everyone better.

What about pairing makes it hard

• Ability to work across ever changing technology stacks is not only expected these days but is also a very important requirement to be a successful engineer who continually provides immense value. But everyone learns at their own pace. Not everyone works best or enjoys working when they are being constantly watched.
• The rules of your organization may require that all work has to be done in pairs. Meaning, every line of code you write, you write with at least one other engineer either sitting next to you or is doing a screen share with you. This can be very exhausting as you have to constantly talk while you write (code).
• While it is expected that an organization will have engineers of varying abilities, and it is important that we all help each other in every which way possible, trying to do 2 things at a time can be less than effective. It is very hard to teach when you are trying to figure out how to solve the problem yourself. Pairing tends to implicitly require that you either constantly stop to answer questions when you code (if you know more), or that you constantly interrupt someone else when they are driving (if they know more).
• It certainly creates more room for conflict. Disagreeing about an approach is sometimes easier as a code review comment than in person because we are all a result of the day that happened before today, and the day that is meant to follow today. Pairing requires that you are always in the best of moods. It would be great if that were to be true but we all know that isn't always the case!
• Last but not the least, you may immensely enjoy coding in quiet and into the wee hours of the night. Pairing simply eliminates that as a possibility. This could be deal breaker for many people. It certainly is for me.

How can an organization make pairing work for all engineers

We are almost 2 pages into pairing so I want to presume we are on the same page with both the agreements and any disagreements as well. So, this wouldn't be a bad time to discuss how pairing can actually help and what potential pitfalls you may want to avoid if you are considering adopting this as practice.

• Give your engineers a choice. Make pairing available as an option but don't make it mandatory. If all the coworkers working on a task (be it a pair or a mob) like the concept of pairing, they should have the option to go for it. But, even if one of them is not game, pick a traditional approach. More importantly, don't single them out for persecution.
• Encourage pairing to be used for certain types of tasks. Not every engineering task needs to be done in pairs or mobs. Some tasks lend themselves to work in isolation while others would benefit from pairing. Trust your team with being able to make that call.
• Pairing 2 strangers is a lot harder than pairing folks who've been in the team for a little bit and know and understand each other well. This takes time. Let your developers pick who they want to pair with.
• Physical proximity introduces a variety of challenges. While it can't be avoided in some types of jobs, software development is certainly not one of them. Even if your team is all local and not remote, give your developers a choice to sit at their desks and pair using a screen share. I am pretty confident people appreciate that freedom and space.
• Pairing requires role play. One of them is the driver while the rest of them are contributors. I think assigning leadership roles (limited to scope of session) in addition will help so when there is some sort of disagreement, the pair or mob can actually move forward. While consensus is great, it doesn't necessarily work all the time. So, division of accountability is just as important as division of labor.

Needless to mention, there is no such thing as a silver bullet. We are all unique individuals who bring unique skills to the table. It would be rather unfortunate if an organization always resorts to picking the next new thing and coercing everyone into accepting it. One of 3 things will happen - (a) the engineer loves it and everything is hunky dory, (b) they loathe it but don't say anything and do what they don't enjoy, or (c) call it quits. Obviously, you don't want to take a gamble.

Respect people, respect their likes and dislikes and trust that a happy employee is a productive employee!