Coding intuitively was one of the first things I was taught by one of my colleagues when I paired with him nearly two years ago.

The idea is that you should code in such a way that your pair can clearly follow your line of thinking based on watching what you are typing. This includes naming variables, methods and classes in a way that communicates their intent.

In addition, we need to make the IDE do most of the work - this means creating variables by typing in 'new MyObject()' and then getting the IDE to handle the assignment for example.

One of the easiest ways to get out of a state of pair flow is to manually type everything - the navigator will lose focus much more quickly and as a result of this possibility it becomes vital that experienced users of an IDE share their knowledge on the shortcuts with other team members.

Using a TDD approach makes it much easier to get into a state of pair flow because there are lots of little goals (i.e. passing tests) that we can achieve along the way which helps to provide a structure around the work that is being done.

The times when I have experienced pair flow have been when I’ve been constantly engaged in design discussion followed by implementing the ideas derived from these discussions.

One of the most effective approaches that I have used when combining pairing and test driven development is ping pong programming - one person writes the test, the other makes it pass, they they write a test and the original person makes it pass.

The benefit of using this approach is that it allows both people to remain focused on the story being worked on, and also provides a useful way to drive out the design.

Talk, talk, talk!

There’s nothing likely to make pair programming painful than a lack of communication between a pair.

I’ve noticed that pairing seems to be at its most effective when the driver is not only coding intuitively but also explaining their thought process along the way. I have lost count of the number of times that I have been describing how I’m planning to do something and my pair points out a better way of doing it.

As a navigator don’t be afraid to ask questions or make suggestions about how to improve the code being written.

Communication doesn’t only have to be at the work station either. Going to a whiteboard and sketching out a design to confirm a dual understanding is equally important.

If the problem being solved is very easy or very boring then pair flow is not going to happen because both people are not engaged.

I posted earlier about some of the situations where there might be some doubt over whether they are suitable for pairing and I think it is important to make sure there is value in what we choose to pair on.

The best tasks for concentrating both people in a pair are ones where there is some complex business logic to implement or where there are significant design decisions to be made in the implementation of a piece of functionality.