Blog

Pair programming tips and tricks

"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"

But as usual with a new approach, it's easy to start with but less easy to start it well. I share with you my experience coding in pair programming hoping to give you some useful advises.

Before to start

Desk set up

Both driver and navigator have to be comfortable. Once, It happened to me to look at the screen from the angle of the desk, while the driver occupied the entire desk as a king!?! Or another time, I worked with someone that turned the screen always in his direction!?

Obviously the driver has to be comfortable with screen and keyboard but also the navigator should see well. Here some solutions:

One bigger screen than usual in the middle (27' for example)

Benefit:

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

Cons:

  • the navigator has to tell exactly what He/She means because switching the keyboard is a little bit uncomfortable but it could be solved using the second keyboard
Using two PCs with screen sharing or live share (for example VS live share)

Benefit:

  • both comfortable
  • both can use the keyboard

Cons:

  • Lags or bad view quality could annoying

Environment and habits

Working with different people each day implies to choose 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 quickly on when working together. Furthermore pair need to synchronize their rhythm: make pause at the same time and be on time at the next session start.

Clearness

A common desk is used by two people instead of one. It means that the space has to be optimized. Pizza box, ten coffee glasses, printed papers of a 1 year old project could obviously reduce the space and make someone uncomfortable. Furthermore, a personal cleaning it's essential.

PC rotation

After 5 days working with my teammate I asked him: "it's the fifth day we use your pc?!" He replied: "Embhe?!" (italian expression that means “what's matter with this”). Using different PCs is important for two reasons. First, it carries to have each pc ready with all set up: a REST service call configuration, preferred links, etc. In this way it's painless working alone or with another. Secondly, one could be shy or uncomfortable using the other's pc.

Role rotation

Another fair rule is to switch often the roles between driver and navigator. There are a lot of reasons for doing it. First, changing roles could change the brain side you are using. The driver has got more focus on solving the local problem and using the keyboard (left side brain, read Pragmatic Thinking and Learning from Andy Hunt to learn more about it). The navigator, instead, is free from using the keyboard, and from the slowness of making things real, so He/She can think quicker and concentrate on the entire picture (right side brain). Furthermore, switching roles creates moments for a pause, keeps both trained for keyboard use, etc. A good starting point could be switching role each 25 minutes with a pause of 5 minutes (The pomodoro technique) Don't skip the pause. Our brain needs to breath to work well.

Ok, we're ready to work together

Share your thoughts

One day as 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 together the best choice. It's pretty fair to think without speech, each one has got his/her way to focus and think. But it's important to share at least the thinking result. Especially when the topic is important. At the beginning of pair programming there are a lot of topic to discuss. It could cause frustration to someone. But after a while the team will create its conventions and common practices and the moments of discussions will decrease. So during each session don't worry to ask "why?" or to tell what you want to do or your idea to your companion. But attention, talking too much without leaving the other the time to think is wrong also!

Be respectful of the other's rhythm

Once, I paired with two dear teammates, very different from each other. The first is very impulsive and pragmatic, so it seems to be faster than me and he stressed me to accelerate my thinking speed. The second is riflessive and calm, so calm that at the beginning it was agonizing working with him (and maybe this time I stressed him to go faster). But on one occasion I discovered we get to the same point at the same time but in different ways: I take two quick thinking steps while He takes only a slow one. So I realized that each one has got his/her 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!" (italian expression for "Trust me!") or generic explanations or, worse, no one at all. That is a lost occasion for both: one to understand really the reason about a particular choice, the other to learn how to explain clearly the concept.

Measure and set the goal

Be focused and measure the time spent are important singularly and double important in pair. It could be useful to subdivide the working time in 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's forcing to setup small and reachable goal. It could increase the focus and the alignment about the next intentions. It could also create data to analyze the performance. "We spent 2 slots (1 hour) to deploy the webapp. Ok maybe we have a problem!". So we can use the data to evaluate our way of work 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 grow our way of work, 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 disoriented, Especially for junior or person that doesn't know well the domain: in fact too many concepts in one shot can create confusion and uncertainty. The uncertainty could be caused also by working always in pair. The "weakest" of the pair uses the other as a crutch and don't fight the fear to do the things alone. Furthermore He/She could have the need to navigate the code with his/her own way and time in order to assimilate it. So mitigate this cons by working alone sometimes.

Avoid to be 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: "Could it be convenient to do this task in pair?"

Suggestions based on role

Navigator

Play the game

The navigator could have different seniority, no matter if He/She participates with ideas or only with questions, the important is that He/She doesn’t act as a spectator but plays the game.

Keep focus

He/She 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 recognize when the driver is loosing himself 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

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

Driver

Fast and correct typing

The driver cannot take seconds to search the exclamation mark on the keyboard. He/She has to be a fast typewriter, if possible write down 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 shortcut

Using shortcuts is much faster than leaving the keyboard, take the mouse, move the pointer and finally click. With practice it's not so difficult to memorize them.

Pc ready

If possible the driver's pc should have all required tools installed, links, credentials, etc. before starting the pair to avoid waste of time.

Keep focus

The driver with the help of a good navigator has to learn how to keep focus on the session goal. He/She has to avoid to look at the chat/mail or to lose himself/herself in unsafe big steps that could have a bad effect on reaching the session goal.

Fabrizio Giovannetti