Last week I wrote a post that gave a quick overview of Extreme Programming, but now I want to talk about my experience with one aspect of XP: pair programming.

I started my software development career at a programming bootcamp. The first nine weeks of the program were entirely remote, so the work that I was doing was rarely seen by others, which for me at that point in my skills dive was completely fine. I did not want anyone to see my code, that is, unless it was HTML or CSS, for which I had a fairly good grasp.

Fast forward to my first day of on site programming, and man, was that a change! From day one I was pair programming, and that would be the norm throughout the nine weeks I was there. For me, that was a bigger adjustment than the pace and the material combined. Before I even got to know anyone there, I had to get over the feeling that my every keystroke was being judged.

I said had in the past tense. I still get that same feeling when the rare pairing opportunities come up now during my apprenticeship. Pairing is a very social activity and I am a very anti-social individual because I am nervous that the high critiques that I have for myself are also experienced towards me by my peers.

With all of the pressure that I feel from pairing, why do I still feel like I need to embrace it? For starters, I am not a silo, and I understand that the majority of my career as a developer will be spent working on a team.

Extreme programming suggests pairing throughout the work day and switching pairs at least once per day. This strategy will ensure that everyone on the team will have an opportunity to pair with everyone else on the team. This also means that the code base is known by all parties of the team, so switching roles and assignments within the team becomes more fluid and much quicker.

Quicker may seem counter-intuitive when you are considering two people working independent of each other versus together on the same screen. The reason that this works is because pairing saves times in other ways.

Besides reducing the amount of time necessary to other team members’ authored code, pairing saves time for the whole application by producing higher quality code. Two eyes looking at the same code, in the moment does increase the time required to produce the code, but the code will contain fewer bugs, saving that discovery time. Bug fixes can be expensive, so there is an economic savings to pairing as well.

On the subject of code quality, think of the benefit similar to that obtained by a code review, except that the review is happening live. A second person brings a second perspective, a second way of thinking.

This came up during my apprenticeship recently where I was solving a problem, but in a weird and inefficient way, and my brain was stuck in that track. My mentor swooped in to give help me think of the problem from a new angle and the fix was very simple. So simple, in fact, that I expressed how silly I felt for even asking. He reassured me that simple answers alude even the most seasoned of programmers sometimes, and that is why having that extra brain or set of eyes can really make a difference. It also reinforces the power of asking for help even if the problem seems simple.

Another benefit of pair programming is shared knowledge. Sure, you share knowledge of the code itself, but a pair can also pick up strategies from the other person to improve her own style. I look at every interaction as an opportunity to learn something new. Even if my mistakes are being pointed out and corrected, I am still learning.

The takeaway here is that even if you are self conscious about your code, pairing gives you an opportunity to improve and learn. Pairing is beneficial to both you personally and the team and project as a whole.