Can You Achieve Flow While Pair Programming?
Why pair programming is bad for introverts and how agile teams can induce flow.
At last week’s retrospective, I asked my team, “Can a developer experience flow while pair programming?” The response really surprised me. I have been developing software for over 20 years - mostly solo. I frequently get into the “flow” while developing. Flow is that state of deep focus and concentration on a task where you can block out the world around you and make incredible progress.
Don’t get me wrong - I have developed as part of a team for my entire career, just never exclusively used pair programming until my most recent project. I have to say that I don’t like pair programming. I much prefer to code on my own. I feel I can achieve flow when working independently, while pair programming wears me out. It’s exhausting. And it takes more time.
The first dev to speak up in response to my question said that he cannot only achieve flow but that pair programming actually enhances and amplifies flow.
I was shocked.
I didn’t think anyone really liked doing it. I didn’t think anyone could be more productive doing it. Why would anyone want to pay 2 devs to write the same amount of code?
Many bloggers and developers have written about why they hate it or love it. This article is not about trying to convince anyone that they should totally embrace pair programming. Nor is it a piece meant to completely deride pair programming.
This article IS about alternative ways to do pair programming if it drives you crazy.
The truth is that (duh!) people are different. Some developers like pair programming, and some hate it (When pair programming sucks). Teams are made up of all kinds. So the question should be more about how to harness each developer’s power. Pair programming is one tool in the tool belt, and it can be used in ways that help OR harm productivity.
Why do we have to do pair programming anyway?
Pair programming has been around for a long time. Like Extreme Programming (XP), several agile methodologies dictate that all programming is done in pairs. The concept is that 2 developers are at least as efficient as if they were working individually AND that the code they produce is of higher quality.
Some have taken this even further and created the terms mob programming, swarming, or ensemble programming. This is where total_devs >= 2 are working together on the same code.
Unless you are lucky enough to own your own company, are the sole software developer, and have a successful solo product, you likely work with other developers. Throughout my career, I have developed solo while working on a team where I would end up pair programming without even realizing it. There were always times when I got stuck on a problem or wanted feedback on a refactor. After experiencing _ actual_ pair programming, I can look back now and see the similarities. So, even as a “solo” dev, there are always interactions where you collaborate with another dev to complete a task.
Tools & Techniques
So the “classical” pair programming approach is to have both developers sitting together with one keyboard. Traditional techniques are:
- Driver & Navigator
- Ping-Pong
- Strong Style
- Maybe others...
I am not going to go into detail about the mechanics and pros/cons of these methods. They have been thoroughly documented. The driver & navigator setup prevails as the underlying arrangement for almost all pair programming. It is the basis for the other 2 in the above list. So you don’t feel like you can achieve flow while pairing with someone else, but your team expects you to pair ALL ... THE ... TIME? What can you do?
The answer is that you should suggest changes that allow for more individual work. You could simply lobby for reducing the percentage of time allocated to pair programming each day. Some teams & their leadership will make this easier or harder to do. You could also suggest some alternative pairing approaches that are outlined below. The goal is to allow developers to get into the flow individually (if that’s what the person needs) while the team still reaps the benefits provided by pair programming.
The following suggestions are based on my own personal experience and what I think makes pair programming more enjoyable and less exhausting - especially for introverts. The techniques are not backed by any scientific data, statistics, or double-blind taste tests. (But I would love to hear from you if you conduct one!)
The traditional techniques of driver-navigator, ping-pong, & strong-style are all communication heavy, and to do them all day is totally exhausting for introverts.
Introverts gather their energy from individual contemplation, not talking through problems on the fly. So here are my ideas on better pair programming techniques for introverts. It’s important to mention here that the pandemic and remote work has opened the door to these techniques. While in-person pairing before the pandemic was done at one machine using one keyboard, pair programming has gone remote just like everything else. In a remote setup, both developers have access to their own machines and keyboards. This provides an opportunity to try these alternative approaches. They can be used remotely OR in-person (close, yet socially distanced proximity).
For devs working together, the easiest way to do this (by far) is to use VSCode LiveShare. Pairs use two machines and work together on the same code using LiveShare. This works the same whether you are remote or in the same room at two different computers. If you have not tried LiveShare, I highly recommend it. It allows one dev to host the session and invite others to join. The host can control who has permission to do what. Both devs can edit and save code as well as run terminal commands, run tests, etc.
The idea behind these techniques is to reap the benefits of pair programming while respecting the social needs of introverts, thus making them more productive.
The old, traditional approaches favor extroverts; these pair programming suggestions favor introverts.
1. Divide and Conquer
For this technique to work, you need a user story easily separable into at least 2 parts. Depending on your product owner and how the stores are written, this could be a challenge. In this setup, the devs still work together to accomplish one user story but take responsibility for different parts. An example of a good story here would be one that has both front-end and back-end changes. I realize some teams write stories limited in scope to one or the other, but some teams do not.
The pair meets together to divvy up the work, then go work on their pieces individually for a while. They can agree on a set time or use something like a Pomodoro timer to work by themselves. The pair then comes back together, reviews the progress that was made, reviews each other’s code, and determines integration points (where their code fits together). They then repeat this process until the story is complete.
2. Show and Tell
This arrangement is similar to Divide and Conquer, except the two devs work together on 2 different, possibly unrelated, user stories. As a solo developer, I like working something out then showing it off. Having to explain your decisions and how the code works, you gain a better understanding of it anyway. The process for this one works like this:
The pair meets to review the stories to be worked on. They decide on a period for individual work, same as above. Here the time box can be a bit longer since the tasks of each dev do not depend on each other. When they come back together, each dev takes a turn explaining and showing the implementation and unit tests to the other. They can talk through any problems and brainstorm better solutions. Repeat until both stories are done.
3. Coder and Tester
Test-Driven Development (TDD) purists may deride me for this one, but here goes. For this technique, the pair works on one user story together. One dev takes on the role of coder and the other tester. The team initially meets to review the story and decide on some of the significant data structures (i.e., what classes, modules, functions, or components are involved). The activity may create some interfaces or data structures that will facilitate their individual work.
Once some of this pre-work is complete, the devs agree on a time period for individual work. The coder goes to work implementing the feature. The tester spends their time coming up with all the ways to break the feature. This can be expressed as unit test pseudo-code while working independently. More detailed the pre-work enables the pseudo-code to be more accurate. After the agreed-upon time, the pair comes back together and converts the unit test pseudo-code into actual unit tests. Once the tests pass, they can complete the story.
Conclusion
Pair programming seems to be more and more the norm on many software teams. The traditional driver and navigator approach favors extroverts. Those that enjoy pair programming likely can get into the “flow” as they team with one or more other developers to complete a task. Introverts need something different to achieve flow. Hopefully, the techniques suggested in this article give introverts a better chance at attaining flow and improving job satisfaction while preserving the benefits that pair programming brings.
So can you achieve flow while pair programming? That’s up to you. Try out some of these different techniques, and let me know how they work out. Every developer on the team has different needs and different things that make them more productive and enjoy their job more. Try mixing it up and see what happens!