In an earlier post about Team Productivity I stumbled upon the idea that while pair programming there could be such a concept as pair flow.
The term ‘flow’ is used to describe a situation where you are totally immersed in the work you’re doing and where time seems to go by without you even noticing.
This can also happen when pair programming and I think there are some factors which can make it more likely.
Code Intuitively/Making the IDE do the work
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.
Test Driven Development
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.
Sufficiently challenging problem
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.