Pair Programming for Collective Learning
Pair programming means that two people write code together on one machine. It is a very collaborative way of working and involves a lot of communication. While a pair of developers work on a task together, they do not only write code but also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions. Teams tend to ship slower over time because they accumulate sub-par code that impedes their progress. Pair programming brings more intellectual firepower to bear on this challenge. A pair of programmers tend to produce better code than someone working alone. Teams that pair often will maintain a fast shipping speed longer. When pairing, fewer corners are cut (and fewer distractions are indulged in). With two sets of eyes, bugs are caught earlier. With two brains to a storm, more creative solutions can be found.
Pairing is two people working together on a single programming problem. The goal is to spread and exchange knowledge rather than concentrate on it. Pairing is the best way, by far, to share knowledge between team members and prevent knowledge silos from forming. You’ll want the help of many eyes to get the best refactoring results. All these benefits come with the price of learning to share knowledge. Aligning the entire team towards the same goal while applying any Refactoring efforts is essential. Pair programming is the second most crucial technique. The combination of both of these techniques leads to higher quality due to the improved feedback loop that the team gets per feature. It can even reduce the time it takes to review if used.
Teams that pair often will maintain a fast shipping speed longer. A team that ships almost always does so because it fights a sub-par codebase. You can write code that minimizes these problems. It’s much more complicated. Teams committed to making pair programming work sometimes pair for 8 hours daily. In my experience, that is not sustainable. You might discover holes in your knowledge or uncover assumptions you didn’t know you had. “How about we extract a method?” “Can we find a better way to do this?” “Should we take a break?”. Admit when you don’t know. Show them how to look it up. Admit when you’re stuck. Show them how you get unblocked. Admit when you’re tired. If you’ve chosen to pair on any problem, ensure it’s because you focus on learning over productivity. Over the long term, leveling up the team’s knowledge is worth more than completing today’s task. You’re likely to learn from this experience as well.
Read through the story and playback to each other on how you understand it. Brainstorm what potential solutions for the problem are. What steps do you need to take for the solution you chose to get there? Pairing is about collaboration and shared ownership. If you’re under too much pressure to focus on learning, don’t pair.
