Pair Program and Feel the Flow

Pair Program and Feel the Flow

Gudny Hauknes, Kari R?ssland, and Ann Katrin Gagnat

iMAGiNE THAT YOU ARE TOTALLY ABSORBED by what you are doing— focused, dedicated, and involved. You may have lost track of time. You prob- ably feel happy. You are experiencing flow. It is difficult to both achieve and maintain flow for a whole team of developers since there are so many interrup- tions, interactions, and other distractions that can easily break it.
If you have already practiced pair programming, you are probably familiar with how pairing contributes to flow. If you have not, we want to use our experiences to motivate you to start right now! To succeed with pair programming, both individual team members and the team as a whole have to put forth some effort.
As a team member, be patient with developers less experienced than you. Con- front your fears about being intimidated by more skilled developers. Realize that people are different, and value it. Be aware of your own strengths and weaknesses, as well as those of other team members. You may be surprised by how much you can learn from your colleagues.
As a team, introduce pair programming to promote distribution of skills and knowledge throughout the project. You should solve your tasks in pairs and rotate pairs and tasks frequently. Agree upon a rule of rotation. Put the rule aside or adjust it when necessary. Our experience is that you do not necessarily need to complete a task before rotating it to another pair. Interrupting a task to pass it to another pair may sound counterintuitive, but we have found that it works.
There are numerous situations where flow can be broken, but where pair pro- gramming helps you keep it:
? Reduce the “truck factor.” It’s a slightly morbid thought experiment, but how many of your team members would have to be hit by a truck before the team became unable to complete the final deliverable? In other words, how dependent is your delivery on certain team members?
??128 97 Things Every Programmer Should Know
?
???????????????Is knowledge privileged or shared? If you have been rotating tasks among pairs, there is always someone else who has the knowledge and can com- plete the work. Your team’s flow is not as affected by the “truck factor.”
? Solve problems effectively. If you are pair programming and you run into a challenging problem, you always have someone to discuss it with. Such dialog is more likely to open up possibilities than if you are stuck by your- self. As the work rotates, your solution will be revisited and reconsidered by the next pair, so it does not matter if you did not choose the optimal solution initially.
? Integrate smoothly. If your current task involves calling another piece of code, you hope the names of the methods, the docs, and the tests are descriptive enough to give you a grasp of what it does. If not, pairing with a developer who was involved in writing that code will give you better overview and faster integration into your own code. Additionally, you can use the discussion as an opportunity to improve the naming, docs, and testing.
? Mitigate interruptions. If someone comes over to ask you a question, or your phone rings, or you have to answer an urgent email, or you have to attend a meeting, your pair programming partner can keep on coding. When you return, your partner is still in the flow and you will quickly catch up and rejoin him.
? Bring new team members up to speed quickly. With pair programming, and a suitable rotation of pairs and tasks, newcomers quickly get to know both the code and the other team members.
Flow makes you incredibly productive. But it is also vulnerable. Do what you can to get it, and hold on to it when you’ve got it!