Strategies for Effective Pair Programming
Pair Development is more than a specific technique to pair. But it is more of a mindset to have about pairing. When you start working on something together, wait to start coding. This early stage of a feature’s life cycle is an excellent opportunity to avoid waste. With four eyes on the problem this early on, catching misunderstandings or missing prerequisites can save you a lot of time later.
Another thing to work on together beyond the code is documentation. Documentation is an excellent example of a task where a pair can keep each other disciplined. Reflect together if there is any documentation necessary for what you’ve done.
While pair programming has a lot of benefits, it also requires practice and might not work from the start. You need to know what you want to achieve with practice to adjust how you do it. The increased focus is one of the benefits of pairing but it can also make it quite intense and exhausting. Pairing or not, taking breaks is essential and increases productivity. Were you alert? Were you tired? What made you feel comfortable, and what did not? Did you switch the keyboard often enough? Did you achieve your goals? Is there anything you would like to try next time? It’s good to make this a routine early on so you practice giving Feedback when something goes wrong. This happens in every delivery team. When a team practices pair programming, the effect of too many meetings can get even worse. If each person pairing has meetings at different times, the interruptions are multiplied. Which meetings do you need? What goals do they have, and how can you improve their quality, for example, with proper preparation, facilitation, and a clear agenda? It is also worth thinking about meeting length and amount.
Ask questions on the how and why can lead to fruitful discussions and better solutions. Try to think about your positionality and situatedness. There are formal hierarchies, for example, between a manager and their report, and informal ones. Models for casual orders are. Can you reflect on your interactions with your pairing partner and how power dynamics impact them? What can you do to neutralize power imbalance? You must use technology for the first time or try a new approach or pattern. Researching and experimenting together works in some constellations. Still, it can also be frustrating because we all have different approaches to figuring out how things work, and we read and learn at different paces. Remember to share your findings with the team. You could have a knowledge exchange session and draw diagrams you can put up in the team space. That is especially true for more introverted folks. But, too many rotations lead to frequent context switching. Don’t rotate for the rotation’s sake. Think about if and why you need to share a particular context and give it enough time to be effective.
Programmers are supposed to be intelligent and crazy-smart. Most people look at what we do and say, ‘I could never do that.’ It makes us feel special and gives us a sense of pride, and pride creates invulnerability. Again, this is about building teams where people trust each other (regular 1:1s, Feedback, a culture where people can ask questions, etc.). There is no simple recipe for persuading others of the efficacy of pair programming. Yet, a key element should always be to talk about it first and ensure that everybody has the same understanding. Make sure to build in opportunities for Feedback and retrospection to share what is going well and what you are struggling with. You can’t force a practice on people, which only works for some. You might end up pairing with only a part of the team — at least in the beginning. How exactly can pair programming be effective for you, how much of it, and for which tasks can vary? Set pair programming as the “sensible default” on teams and discuss whenever the team wants to make an exception.
