Pair programming basically means that two people write code together on one machine. While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work.
As someone who has been learning coding alone for a long time, it came as somewhat strange concept when I first heard about it at the Bootcamp. I’ve had no problem doing it all by myself — Why can’t I just do it alone? Pairing would force a constant conversation with each other to find common ground with the other person’s ways of thinking, which can be pretty energy draining.
Well, it didn’t take too long to understand that the advantages of pair programming surpasses its disadvantages after experiencing several group projects. I’d like to share why I felt I was benefiting from it:
- Knowledge Sharing: Having two people work on a piece of the code helps the team spread knowledge on technology and domain on a daily basis and prevents silos of knowledge.
- Keeping Focus: It’s a lot easier to have a structured approach when there are two people collaborating together. Each individual has to explicitly communicate why they are doing something and where they are heading. When working solo, you can get distracted a lot easier.
- Collective Code Ownership: Consistent pairing makes sure that every line of code was touched or seen by at least 2 people. This increases the chances that anyone on the team feels comfortable changing the code almost anywhere.
- Code Review: Typos and errors will have higher chance to meet the eye when worked as a team. It’s also easier to improve code when you have someone beside you because you can discuss approaches or the naming of things for example.
It’s tempting to avoid pair programming because it can create friction, but it’s really worth to give it a chance. Without pairing, you may still achieve the advantages mentioned above, but it works even more effectively when it is done well and your team genuinely wants to do pairing.
