Imagine that you are completely absorbed in your work: focused, passionate, and busy. You have lost track of time. You are happy. You are in a state of flow. On a larger scale, it is difficult for an entire team of developers to achieve and maintain a state of flow due to numerous interruptions, distractions, and other obstacles that can easily disrupt it.
If you have already participated in pair programming, you probably know how it contributes to achieving a state of flow. If not, we want to share our experience to encourage you to start pair programming immediately! For pair programming to be successful, some effort is required from individual team members and the entire team as a whole.
Being part of a team, show patience towards less experienced developers. Overcome your fear of more experienced developers. Realize that everyone is different and learn to appreciate that. Remember the strengths and weaknesses—both your own and those of other team members. You might be surprised by how much your colleagues can teach you.
Apply pair programming to disseminate skills and knowledge among all project participants. Tasks should be solved in pairs, and participants and tasks should be frequently rotated. Together, establish a rule for such rotation. If necessary, abandon or adjust this rule. Our experience shows that it is not essential to complete a task before passing it to the next pair. It may seem unreasonable, but in practice, we have found it to be effective.
There are many situations where the flow state can be disrupted, but pair programming allows it to be maintained:
The role of the “truck factor” is diminishing. Here’s a slightly scary thought experiment: how many members of your team would have to be hit by a truck for the final product to be impossible to deliver? In other words, how much does the delivery of your final product depend on specific team members? Are the knowledge and skills a privilege or are they widely available? If you rotate tasks between pairs, there will always be someone else who has the knowledge needed to complete the work. The state of your team’s flow will not be affected by the “truck factor.”
Problems are solved effectively. If you are programming in pairs and encounter a complex issue, you always have someone to discuss it with. In such a dialogue, solutions will be found more quickly than if you were struggling with the problem alone. As a result of task rotation within the team, your solution will be reviewed and critically evaluated by the next pair, so it is not so important if your initial solution turns out to be suboptimal.
The integration is going smoothly. If your current task requires accessing another piece of code, you can hope that the method names, documentation, and tests are sufficiently informative to give you an idea of what this code does. If not, by working in pairs with the author of this code fragment, you will be able to understand it better and integrate it into your code more quickly. Additionally, during the discussion process, you will have the opportunity to improve naming, documentation, and testing methods.
You can be interrupted without any pain. If someone comes up to you with a question, or the phone rings, or you need to urgently respond to an email, or you need to attend a meeting, your pair programming partner can continue working on the code. When you return, your partner will still be in the flow state, and you will be able to quickly catch up and join them.
New team members quickly integrate into the project. If pair programming is used in the team and the rotation of pairs and tasks is properly organized, newcomers quickly become familiar with both the code and the other team members.
Flow provides incredible productivity. But this state is easy to lose. Do everything you can to enter the work flow, and then, once you’ve succeeded, stay in it!