Love, caffeine and omlette

Tag: pair programming

A short primer on Pair Programming

When I started to pair programm I had absolutely no idea what I was doing. I sat next to another programmer and we started. Sometimes it worked but more often it was frustrating.

Maybe you are new to pair programming and want to give it a try, or you have trouble getting started. Then this blog post is for you.

I show you how we pair at Some of this advice is really obvious - but much of the other stuff we figured out the hard way through pairing over and over again.

Thinking together

Preparations for your first pairing session

Probably your workspace is not prepared for 2 people working on it for an extended amount of time. So before you even begin: Be a good host: *Adjust your environment for pairing. *

Physical preparation of your workspace

Move away the piles of paper, the dishes and your backpack under the table. Clean your table. Don't let the navigator feel like he is just visitor.

Now move 2 chairs in front of the table. If you do not pair all the time it is also ok to keep a few spare chairs scattered through the office.

Prepare your hardware

Now take a good look at your screen(s). Can you see them from both perspectives? Is the contrast high enough?

Especially with notebook screens it can happen that the person sitting next to you will have such a bad contrast that it might be hard for your pair to see what you are doing. If this is the case get a monitor that both of you can watch.

Place a second mouse/keyboard combo on your desk. It's nice for the navigator to point to code or be able to write a chunk of pseudocode and it costs nearly nothing.

Prepare your computer

Adjust your font size to 16px or 18px. I know this seems ridicullisly big but it will be much nicer for the navigator to look at it. (And also for you of course)

Now close all your programms. E-Mail clients, IRC, Instant Messenger are a no-no during pairing in my opinion. You will have time for checking this stuff in between the pairing session.

Prepare an editor/IDE that both of you can use. Get an environment ready that works, check out the project, run the tests.

Talk to your partner

You should know each others schedule. I find it frustraiting if my pair has to leave in 15 minutes. Better to know in advance.

Grab Essential tools

Now the navigator should grab a notepad and a pencil. Also prepare a timer.

A kitchen timer works fine, alternatively search for "Pomodoro Timer" on Google.

Immediately before every session

Grab a coffee, go to the restroom and prepare yourself to focus for the next 25 minutes. Close open loops that might distract you during this time.

The first pairing session

At the beginning of each session the navigator sets the timer to 25 minutes.

Then talk about what you want to do on a high level. Both of you should have a good idea about the scope of the task ahead and what steps are involved.

If the taks contains of multiple steps the navigator should write down a list off these steps.

Write a test first

Pick the best step to start with and write the first test. Try to get the test right, so you both understand what needs to be done.

TDD is especially effective in combination with pairing, it communicates what you want to do and it will focus both of you on the next step.


Now the drivers your responsibility is to implement the code. Explain what you are doing along the way. Do not concentrate that much on the big picture, but try to get the task at hand done. Trust your navigator to keep the larger picture in sight.

Whenever there are alternatives ways to do it and you are not sure - ask your navigator what to do.

Let the navigator guide you through the list of tasks. Ask him how to proceed if you are unsure.

Ensure that you work on the tasks on the list.

If you discover additional tasks - it often does make sense to postpone them and focus back on the problem at hand. It's your responibility that both of you don't forget them - so note them down.

Keep engaged with the driver and try to understand what the driver does.

When you notice that the Driver get's stuck unstuck him. Even if you don't know the answer to the problem at hand - ask him a question.

Point out typos or problems if the driver does not see them himself. Is the code understandable? Are the variable names ok? Is the class getting to bloated? Do a on the fly code review. Mention problems. But do not micromanage of course. - Just like in a normal code review.

Pull the driver out of the implementation if you have the feeling that you should change the angle. Discuss it with him.

Talk, talk, talk!

Talk, talk, talk!

You should communicate all the time! In a good pairing session it really feels like you are working on this in unison. As the driver you can focus on getting the tests past and as the navigator you can keep the pair going in the right direction, ensuring an excellent quality.

Communicating right is maybe the hardest part for most programmers - just keep doing it. It's a skill that you can aquire and if the pair is really attuned to each other after many session this will feel like second nature to you.

General behavior

Concentrate at the task at hand for 25 minutes. Do not watch your emails, do not take breaks, try to stay engaged. It is really expensive for 2 programmers to become distracted.

Work step by step from your list. After you have finished a step take it off the list and start working on the next step.

Don't argue to much. This is not an ego game - if both of your solutions are equivalent just decide and keep going 😉

After the session

The session ends after 25 minutes. Take a break of at least 5 minutes. This is the time to grab a coffee, to visit the toilet, check your mails and take a break.

Good pairing is intensive. You will need the break especially if you want to work for a few hours in a pair.

After each pairing session switch roles. We solve this with a WIP commit to the feature branch, then we change workstations.

After the your break is over start another pairing session if needed.


Getting started with pairing is no easy feat. Don't get discurraged. It is worth to learn it.

In a future blog post I will describe the many many problems that you might encounter during pairing and how to tackle them.

I hope after reading this little primer you get the idea how this could work and be sustainable. Since this are not best practices by any means, feel free to implement pairing your own way.

If you have experience pairing or tried this out: What are your thoughts about this? How do you pair?

Pair Programming - The why.

Pair Programming means that 2 programmers work on the same problem together at one workstation.
One of them is the driver - the guy who writes the code. The other programmer is the navigator who things on a more strategical level, helps with fresh ideas and asks questions. Both of them should switch frequently.

Pair programming
Pair programming from Syneus Solutions. (CC BY-NC-SA 2.0)

For most programmers this is completely unfamiliar in the beginning. It's not very easy to learn - and it's not for everyone. But learning to pair can be worth it.

Benefits of Pair Programming

Zero friction reviews

Do you do Code Reviews? We at Helpster have the 4-Eyes-Rule: Every piece of code has to be verified by a second pair of eyes.

Pair Programming of course offer just that. You have constant review of your code. And even better: You can directly incorporate it into your code.

Live up to your own standards

Do you have high standards? Do you want to do TDD for example? Do you wan't nice commit messages? Do you want to talk to your Product Manages more often? Write code that the whole team understands? We do!

Pair Programming is great to live up to your own standards: A good navigator has time to think about all of this. It's so much harder to be sloppy, when you are tired if your pair is watching you 😉

Teamwide learning

I learned so much from my pairs, during the last years. Of course you can learn small tricks like using ClusterSSH to admininster servers, or a short hand to create new files. But you might also find yourself using Vim and ask yourself how the hell you can work with it.

You learn a lot during a Pair programming session
Fall 2011 Student Hackathon Coding from @matylda. (CC BY-SA 2.0)

Often you implement something that your pair wanted and the solution is very nice and elegant - more then any of you two might have achived.

Since pairs should switch frequently there is a very good knowedge distribution within the team after a while.

Concentration & Relaxation

A good partner can motivate you. Even the crappiest chore looks way better if you have someone that shares you're pain.

There are fever distractions in a pai. You do not get distracted from the outside or your own emails that often. And you have a good excuse to enforce you're Pomodoros 😉

It's just fun

Last but not least it's just fun. As a driver you have a navigator that
unstucks you all the time and gives you valuable feedback. Even the
worst tasks are just done.

It's very intense and rewarding and at the end of the day you end up
with code that is much better, then what you would have written - but you are also crushed. You go home after 8 hours and feel very good about it.


Pair Programming has a lot of advantages. It's very different in the
beginning, but it can be very nice in the end.

Of course there is not only light. But let's cover this in the next article 😉

Command line tapas: Feel like a hacker with cluster ssh

A few months ago I paired on a chef recipe with a colleague. After we
uploaded the cookbook we wanted to try this stuff out on a few nodes.

Until then I would have kind of done it completely manually. But he
entered a command and the following happend:

ClusterSSH in action

Wow. He just ssh'ed into all of these servers. The next part looked even
cooler. He started typing and magically the text appeared in all the
terminals. He pressed enter and the chef run started. It looked awesome. Chef runs produce quite a lot of text 😉

I was hooked and asked him what he just did. "That's just ClusterSSH", he
replied, "I use it all the time".

ClusterSSH is a tool for making the same change on multiple servers at
the same time. The 'cssh' command opens an administration console and
an xterm to all specified hosts. Any text typed into the
administration console is replicated to all windows. All windows may
also be typed into directly.

For the Mac there is a similar tool called csshx thats what I ended
up using.

It works like a charm. You just specify your clusters in a clusterfile.

cluster1 host1 host2
cluster2 host3 host4

Now you just enter:

csshx cluster1

That's it.

I use csshx during every maintainance window. I love
pair programming. Makes you realize that things that are obvious to
yourself are not obvious to your colleagues.

© 2017

Theme by Anders NorenUp ↑