For the last year I have been writing “most” of my production code together with at least one of my team members. It took me a couple of weeks to get comfortable with the practice, but at this moment I could not think of a better way to write better code faster and maximize knowledge sharing within the team.

So here are some of my takeaways regarding pair programming.

Results in better code faster

The code a pair writes usually is of a higher quality as it is reviewed while it is being written. So when a feature is finished and ready to be integrated, there is no extensive review phase. There is very little or no rework; all the big issues were already discussed and addressed while writing the code. The only thing I do is check the pull request to see if there are any minor issues we missed.

When all code is written in pairs, it seems you can only do half the work a team would normally do, but you have to take into account the benefits that will last long after the work is finished.

Best way to share knowledge

The best way to share knowledge is to have an experienced team member pair with an inexperienced team member. Most of the developers I have worked with like to share their knowledge, but they often find it difficult to transfer this in a natural way. When a pair sits together and works on a problem, the gaps in knowledge are filled automatically. Not every developer is a teacher, but every developer is comfortable behind an IDE talking about code.

And when two team members have implemented (part of) a certain feature, there is no large impact on the planning when a team member gets sick. There is always another team member who has knowledge about the feature and can continue the work.

Requires more effort

Practicing pair programming seemed to me like you have to be ‘on’ all the time. When practicing pair programming there is, besides working on programming problems in my own head, also the discussions with the partner. When I was going at it alone, I could focus on the problem in front of me. The discussions with team members also took place, but usually after ‘finishing’ a task during the code review phase and often offline.

Having the feeling of being constantly ‘on’ can be tiring when you don’t (know how to) handle it. So my advice is; take breaks during the day (using the pomodoro technique) and stop pairing when you feel mentally drained.

Not for all production code?

I do not practice pair programming all the time. When changes are trivial or very clearly defined, one team member will implement them. During the review no surprises are expected. At the other end of the spectrum there are changes that are not trivial and not clearly defined. At this point, whatever I am writing cannot be regarded as production code, but proof-of-concept code which you should always throw away. I find searching and reading documentation difficult when pairing. At this point it is sometimes best to break up for a few hours, work out some ideas separately and discuss them when you have a better picture of the required changes.

–

When you have knowledge silos, large or toxic code reviews, high rework on finished features or want to create a better bond with your team members try pair programming for a few sprints and see what it can do for you!