Pair Programming means all production software is developed by two people sitting at the same machine. The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. (agilealliance.org)

But as usual with a new approach, it’s easy to start but less easy to start well. I would like to share with you my experience pair programming while hoping to give you some useful advice.

Before starting

Desk setup

Both driver and navigator have to be comfortable. Once it happened that I was trying to see the screen from the corner of the desk while the driver occupied the whole desk like a king! Another time I worked with someone who always turned the screen in his direction!

Obviously, the driver has to be comfortable with the screen and keyboard but the navigator should also be able to see properly too. Here are some solutions:

A larger than usual screen in the middle (27” for example)

Benefits:

• driver and navigator have the same conditions
• while the driver has the keyboard in front of them, the navigator has the space for a notebook or a second keyboard

Cons:

• the navigator has to explain exactly what they mean because switching the keyboard is a little bit uncomfortable, but it could be solved using a second keyboard

Using two PCs with screen sharing or live share (for example VS live share)

Benefits:

• both comfortable
• both can use the keyboard

Cons:

• Lags or bad view quality could be annoying

Environment and habits

Working with different people each day implies choosing a common environment and similar habits. For example, someone could have difficulty reading a small font or could have different shortcut configurations. The team should find a compromise and create a preset to switch on quickly when working together. Furthermore pairs need to synchronise their rhythm: having breaks at the same time and be on time at the start of each session.

Cleanliness

A common desk is used by two people instead of one. This means that the space has to be optimised. A pizza box, ten coffee glasses, printed paper from a 1-year-old project could obviously reduce the space and make someone uncomfortable. Furthermore, personal hygiene is essential.

PC rotation

After 5 days working with my teammate, I asked him: “is it the fifth day we use your PC?!” He replied: “Embhe?!” (an Italian expression that means “what’s matter with that”). Using different PCs is important for two reasons. Firstly, it carries to have each pc ready with all set up: a REST service call configuration, preferred links, etc. This makes it painless working alone or with somebody else. Secondly, one could be shy or uncomfortable using someone else’s PC.

Role rotation

Another good rule is to switch the roles between driver and navigator often. There are a lot of reasons for doing this. Firstly, changing roles could change the side of the brain you are using. The driver has more focus on solving the local problem and using the keyboard (left side of the brain - read Pragmatic Thinking and Learning from Andy Hunt to learn more about this). On the other side, the navigator is free from using the keyboard, and from the slowness of making things real, so they can think quicker and concentrate on the entire picture (right side brain). Furthermore, switching roles creates moments for a break, keeps both trained in using the keyboard, etc. A good starting point could be to switch roles every 25 minutes with a break of 5 minutes (The pomodoro technique). Don’t skip the break. Our brain needs breathing time to work well.

Ok, we’re ready to work together

Share your thoughts

One day as a navigator I spent 15 minutes looking at the screen without hearing a word from my colleague. He was too busy to think and write down his solution. One of the benefits of pair programming is comparing different points of view, talking about pros and cons of different ideas and choosing the best choice together. It’s quite ok to think without talking, each one has their own way to focus and think. But it’s important to share at least the result or the thinking. Especially when the topic is important. At the beginning of pair programming there are a lot of topics to discuss. It could cause frustration for someone. But after a while the team will create its own conventions and common practices and the moments of discussion will decrease. So during each session don’t worry about asking “why?” or to say what you want to do or your idea to your companion. But pay attention: talking too much without leaving the other the time to think is also wrong!

Be respectful of the other persons rhythm

Once, I paired with two dear teammates, very different from each other. The first one was very impulsive and pragmatic, so he seemed to be faster than me and this stressed me to accelerate my thinking speed. The second one was reflective and calm, so calm that at the beginning it was agonizing working with him (and maybe this time I stressed him to go faster). I soon realised that we got to the same point at the same time, but in different ways: I took two quick thinking steps while he took one slow one. I realised that each one has got their own thinking speed and there is nothing wrong with it. So be respectful of the other’s rhythm.

Ask and give explanations

Be aware of expressions like “Fidate!” (Romanesque expression for “Trust me!”) or generic explanations or, worse, none at all. That is a lost occasion for both people: one to really understand the reason for a particular choice, the other to learn how to explain the concept clearly.

Measure and set a goal

“Be focused” and “measure the time spent” are important individually and doubly important in pair programming. It might be useful to split the working time into fixed time sessions and decide the goal of each session at the beginning (the pomodoro technique concept). The session length should be short, 30 minutes for example, so that it forces to define small and achievable goals. It could increase the focus and the alignment about the next intentions. It could also create data to analyse the performance. “We spent 2 slots (1 hour) to deploy the webapp. Ok maybe we have a problem!“. So we can use data to evaluate our way of working and calculate the ROI of our job. Or we can use them as support material when we want to convince the Product Owner and the stakeholders that some technical improvements, process change, etc. should be done.

Pair rotation

Working with another person can improve our way of working, share knowledge or teach something new, a good tip, a new tool, etc. It can also teach how to handle people with different personalities. These benefits increase proportionally with the number of people you work with. But switching too often, for example daily, can be disorienting, especially for juniors or people that don’t know the domain well: in fact too many concepts in one shot can create confusion and uncertainty. Uncertainty could also be caused by always working in pairs. The “weakest” of the pair uses the other as a crutch and doesn’t fight the fear to do things alone. Furthermore they could have the need to navigate the code with their own way and time in order to fully understand it. So mitigate these cons by working alone sometimes.

Avoid being strict

Pair programming, as all tools, has got pros and cons. So don’t apply it religiously, evaluate it measuring the ROI of its usage in different scenarios. Ask yourself: “Would it be convenient to do this task in pair?”

Suggestions based on role

Navigator

Play the game

The navigator could have a different seniority, it doesn’t matter if they only participate with ideas or questions, the important thing is that they don’t act as a spectator but also play the game.

Keep focus

They could be tempted to look at the chat/mail, talk with other teammates, talk about the weather to the pair and so on. It could lead both to lose focus. It could be acceptable during less important activities (releasing in QA for example) but it’s better to avoid it during a refactoring session and other important activities.

Keeping the driver focused

The navigator has to check that the driver is following the session goal and recognise when the driver is losing themselves in a huge refactoring or is performing unsafe steps.

Don’t dictate

“Write ‘buy’ and open the parenthesis”. Please, don’t do it. It could be irritating and is not useful. Instead, suggest some tips and tricks ignored by the driver that could speed up the work. For example a shortcut (CTRL+G in Intellij Idea for Mac it’s a classic!) or an alternative way to do something and so on.

Take notes

Writing down open points, the next test cases, the next todos, the questions for another department, etc. is a good habit to avoid forgetting something. Taking notes postpones topics out of scope helping the pair to be more relaxed and focused. Furthermore it’s a pleasure to strike through the completed task!

Driver

Fast and correct typing

The driver should not take seconds to search the exclamation mark on the keyboard. They have to be a fast typist, if possible typing without looking at the keyboard, using ten fingers and typing without errors. Fortunately it’s only a matter of knowing some basic rules and doing some practice, for example on typing.com

Use the keyboard shortcuts

Using shortcuts is much faster than leaving the keyboard, taking the mouse, moving the pointer and finally clicking. With practice it’s not so difficult to memorise them.

PC ready

If possible, to avoid wasting time, the driver’s PC should have all the required tools installed, links, credentials, etc. configured before starting pairing.

Keep focus

The driver with the help of a good navigator has to learn how to keep focus on the session goal. They have to avoid looking at the chat/mail or losing themselves in unsafe big steps that could have a bad effect on reaching this goal.

Originally posted on http://fabriziogiovannetti.com/blog/pair-programming-tips-tricks/43