Pair Programming

Pair programming is a great way to see a problem from a different perspective. It gives you the opportunity to learn and be inspired by the people around you. And most of all, it stops you from tunnelling in on a problem and going down the wrong path for too long.

Pair-programming is a great strategy for us to foster collaboration, communication and come up with better results overall:

• Fewer bugs and errors are introduced as a result (significantly reducing development costs and directly addressing some of the cards raised)
• Provides a space to align and prevent conflicts later (also more consistent code style)
• Reduces dependancies ("lottery factor") over time as more people get onboarded to the features
• Creates a shared ownership and shares responsibility
• Stops from going down the wrong path for too long. When people work on their own, they sometimes get stuck on a problem, with a partner you are more likely to try different solutions

There are great resources on pair programming out there to get inspired. For example on Martin Fowlers blog or watch this great talk on pair programming by Brigitta Böckeler:

We encourage all our engineers to join forces and code together as often as they see fit, even across teams and disciplines. In order for such an exercise to be fruitful, it is important to remember that not everyone has the same approach to coding, problem solving and learning, and that differences in domain and technical knowledge play a big role in whether or not both participants will benefit from the session. To make the most out of pair-programming, please consider the following guidelines:

1. Define upfront the duration and scope of the session. Is it going to be for a certain amount of time or will it last until the whole feature is being done (with appropriate breaks)? Make things clear from the get-go to avoid mismatches in expectations in terms of what is being achieved.
2. Let the least experienced engineer (whether it’s in terms of domain/product or technical expertise) be the one with control. Because they are the one with the steeper learning curve, they might be slower which is why they should lead the pace. Having the most comfortable engineer being the one with keyboard control leads to a spectating session, not pair-programming.
3. Regularly asking for confirmation or feedback to make sure both participants are on the same track and no one feels lost. For longer sessions, do not forget to suggest or ask for small breaks. Pair-programming doesn’t mean having tunnel-vision for hours on end.

To get you started, check out the 7 principles of pair programming