I always prefer to work with a colleague instead of working on my own. But, I've seen many organisations in which the devs run away from the practice of working together in such a way.  Pair Programming isn’t just for complicated cases, or to teach someone, but is a day to day technique of working. 

Opinions are often not well funded. And, when asked why devs don’t like to work like this, three common answers come back: “It’s a waste of time” (What they really mean is, I don’t have time to do it), “It's one dev working, and one dev watching” (I don’t get to code by watching) or “I don’t like it” (I prefer to listen to music while I work)

What is Pair Programming?

Real Pair Programming is a technique that involves two roles: driver and navigator. 

The driver uses the keyboard and has a TACTICAL way of thinking, solving the current problem writing the code. To do that they NEED to say out loud each line of code written. They are continuously speaking,. Explaining what they are doing and, maybe, even why it is being done.

On the other hand, the navigator is thinking strategically, looking at the big picture, what is coming next, what is the impact in the system, when was the last commit, how are the edge cases in the system, what about these other libraries... The navigator is listening to the driver, but also asking questions, thinking alternatives, and providing feedback.

And, they swap often.

The rule is, "for something to get from your head to the computer, it MUST go through the OTHER person."

Why should we do Pair Programming?

A question easier answered using Socratic maieutics.

It’s a conversation I love to have with people already using Pair Programming, but reluctant to use it frequently. So, when I start asking questions to evolve the thinking, we usually end in the same conclusion:

• There is an increment in the quality of the code: Two people looking, thinking and talking about code, makes the code better, with fewer errors. Yes, you have a faster code compiler in your colleague!. There is a long conversation here about "do we need Pair Reviews if we are doing Pair Programming?" and while this question can create an entire blog post of its own, the short answer is: No, you don't.
• More homogeneous code. As there are more people involved, the solutions are more aligned, and the style of code too. It's easier to follow code standards if there are two people checking each other for it.
  
• More knowledge sharing. This one is clear; more people are involved, more people know about it. So, less bus factor, fewer risks, and devs are more engaged with the product because they know it more.
  
• Focus. Let's be real. We live in a world full of distractions, notifications, slack pings, urgent emails not that urgent, etc. But, do you check your notifications when someone is sitting with you having a conversation??? So, it is that. You are focused on your partner and the code, and nothing else. Also, remember that it is easier for someone in the office to interrupt one person alone, than two people working together.
  
• Shorter feedback cycle. And this is what Agile is about; have as short cycles as possible, so we can do the right things right. Someone at your side is giving you instant feedback, how much faster can be using any other technique?

 All these benefits will apply to the mid-long term in the project, so I have to concede that not always the value is perceived in the short term, (irony_mode = on)but we are just touching this system for a couple of months more, right? (irony_mode = off)

 So, every second we are not doing Pair Programming our code has less quality, it's less homogeneous, the knowledge flows less and we need to do a bigger effort to share it, we can be distracted more often and the feedback cycles are longer.

Are there different Pair Programming Scenarios?

I have identified these common four scenarios, based on the driver and navigator's system knowledge.

One of the biggest mistakes I've seen in a lot of teams is using Pair Programming to ramp up a new team member, and putting the new team member as a navigator in the pair. In my opinion, this is extremely ineffective. A new team member, that doesn't know the system, can't have the strategic approach to the problem. The new member of the team needs to display a strong personality to speak up and say when they don't understand something the process then end in a silent navigator, getting low knowledge about the system, and a driver speaking less and less and writing code faster to meet an impending deadline, dragged by a new team member. Thus creating a negative training experience. If you want to teach, set the teaching and the ramp -up as the goal, and let the new team member be the driver.

Why do people not use Pair Programming? 

It is not about code. It is not a technical skill. I Repeat: it is not about code. Let it sink in.

Pair Programming is a social skill. It's all about communication and relationships. And we, devs, are not trained in college or in high school in social skills. So, does it work only if you are a naturally social extrovert with good communication?No, you don't need to be extroverted,. Introverts and quiet people are great  Pair Programming too;. It’s no tough JUST because you are not a natural social beast, it's tough for EVERYONE, but worthy).

The positive aspect is that it is a skill,  And, like with any skill you can learn how to do it better. Let me share some learning that I've got during my time doing Pair Programming.

The Do's and Don'ts of Pair Programming

 Start with agreeing on the environment together. The physical space, the IDE configuration, everything. 

There are people that hate when someone touches the screen, and then there are monsters that love to point at the screen and leave their fingerprints marks. I'm one of these monsters. There are people who like several tabs in the IDE, and other people just like one tab per screen. Also, in pandemic times, there are people more sensitive to others touching their mouse or keyboard. So let's make it work and talk in advance and agree on how we like to work. If needed, use a double keyboard, mouse and a switch.

 But it is not just about the physical space, you also need to agree on the coding standards, principles to use, etc. Set the common ground and the goal, but more importantly, clarify what means "better". Sometimes we argue a lot about which solution is "better", without defining what that means. My best advice on that is to clarify it. In that scenario, is it better to look for readability? performance? reusability? follow the principles? use standards? No matter what, before starting to argue about code, define what is the goal, and what means "better".

When you are talking about code, be explicit and over communicate, don't let the assumptions blow up the conversation. 

And, like any couple in life, it's better if you pay attention to the other person and show empathy, listen to them. Being clear, empathic, assertive, respectful makes everything easier. Remember, this is not a war, it is not a fight, there is no way for you to win alone, because you are together, and you both want the same outcome. So, leave space, accept different approaches and focus on building the relationship. Also, listen to the feedback and accept corrections, but provide them too!

Little trick: Good partners are open to trying the other person approach.

Second little trick: Provide feedback, but also GOOD feedback and as many compliments as you can. If the other person is doing things right, just tell them! We all like to hear that we are doing good things. Be kind and nice, without sounding patronising.

 So, as you can imagine, to be aware of all of this, and to spend hours in the day on it is...... exhausting. So, we need to take frequent breaks. Don't hesitate, break often. Go for a coffee, talk about the last film you saw or whatever. But don't let your body and mind fall in a short-circuit. It's more damaging than you think. What do you think if you are doing something with someone that you FEEL is not paying attention to you?

But probably the worst behaviour is to betray the trust of your partner, changing the code. If you agree to approach the code in some way, don’t change it without your partner's approval. The worst thing is when you go to the toilet and when you come back everything is different because “I think it was the best way to do it”. It’s a betrayal. It’s breaking the first and only rule. Don’t do that.

Pair Programming is also about our feelings, we are humans, and we need to be aware of how each other is feeling. Also, we need to be aware of our own feelings, we might have a bad day because of a traffic jam or because our baby is sick. So be open, share, and be aware of how you are reacting. Is not about a negative reaction, but about what you do in the next 5 seconds. If I have a bad reaction and I leave it there, then you will think one (probably bad) thing about me, but if in the next seconds I apologize and explain my reaction, probably you will think differently about me.

Conclusion

 Remember, when you start Pair Programming, it feels weird, exhausting and requires discipline. That is ok. This feeling happens to everyone at the beginning. Just relax and continue together.

 Sometimes we are scared about being perceived as bad devs, or the opposite. But remember, don’t worry about Pair Programming, you are not as good as you think you are, neither as bad as you fear. We all learn from others and we all give something to others. Don’t forget in which scenario you are.

 So, it's just about being a nice person.

 Don't express superiority, or never back down. Don't stay in silence, coding alone. Everyone likes to have the keyboard, so swap often and let everyone have fun. Don't try to win, or make the situation all or nothing, or complain continuously. Just be nice.

PS: What about remote Pair Programming? We'll have another blog post about Pair Programming remotely. But, SPOILER ALERT: It's the same :-P