Rethinking Pair Programming

By default, we always do our work in pairs. We strongly believe that the quality achieved by two people working on the same task is superior to when done by a single person. However, there are times where pairing is not very efficient.

Pair programming pitfalls

In a professional environment, pairing with developers who have a different software development foundation can be slow, tiring, and quite frustrating. Let’s explore a few pair programming pitfalls.

Pair programming can be slow and frustrating

Having to explain and agree on every single variable name can be extremely annoying. Things get even worse when discussing design decisions. Debates can last minutes, if not hours. Frustration kicks in. How many times, while pairing, we though: “Oh, come on man. How can you disagree with this? It’s common sense. Can we stop debating and just finish the bloody story?” Over the years I came to learn that common sense doesn’t exist. It’s only a phrase people use when they run out of arguments.

How to improve it: Pair-programming becomes far more efficient and pleasant when developers don’t need to discuss basic concepts like the size of a method, Single Responsibility Principle, how to name a variable, and some basic software design principles. When developers have a similar foundation, they can purely focus on finding a better solution to the problem instead of wasting their time with unnecessary discussions. One way to bring the whole team to the same level of understanding is to organise regular technical meetings (hands-on sessions, book club, roundtable discussions, etc.), define team standards, retrospectives, and code reviews.

Pair programming can be very tiring

Spending the whole day pairing with someone can be very tiring. We need to justify and agree on every single line of code. Things that are trivial for one developer may not be as trivial for another developer. As eXtreme Programming becomes more popular, pair programming is becoming mandated in certain companies. Developers are asked to arrive at the same time, break for lunch at the same time, and leave at the same time, just because they need to be pairing full time. By the end of the day, developers are exhausted, as they had no time for themselves.

How to improve it: Developers need some alone time. Regular breaks are important. Using the Pomodoro technique is a good way to force regular breaks. More tips below.

Pair programming can stifle creativity

One of our clients recently asked me if their UX and UI teams should also do their work in pairs. Overall, I think it is a good idea, however, there are times that you need space to create and innovate. There are times when you have a few half-baked ideas you want to explore but you are not in a position to verbalise them yet. This is also true for software design. Sometimes, we need some alone time in order to create. Creativity and innovation very rarely emerge in an environment where you are pressured by time or by a person sitting next to you waiting for you to explain what you are planning to do.

How to improve it: It should be OK for any team member to express her desire to work on a task alone. That doesn’t mean that other team members will not review her work. After working alone for a short period of time, the person could then present her ideas to the rest of the team and choose a pair to polish and finish the work.

Inexperienced developers not always benefit from pairing

Pair programming is a great way to mentor inexperienced developers. However, it cannot happen 100% of the time. Speaking to our apprentices, they said that although it was great to have someone teaching them full time, they also needed some time alone to do their own research and make their own mistakes. Developers learn by doing it and they need some space to do things at their own speed. Our apprentices felt that although they were learning a lot from our craftsmen, they were not assimilating everything.

Pairing an experienced developer with an inexperienced developer is a great way to give the inexperienced developer an idea of how things work. However, the side effect of this is not always positive: the inexperienced developer ends up not spending enough time researching, trying things out, and making mistakes. The inexperienced developer may learn how the more experienced developer does things but she can’t fully understand why.

How to improve it: A better way to mentor inexperienced developers would be to start a task as a pair, give some high-level directions, and then let the inexperienced developer do the task on her own. If she gets stuck, she can always ask for help. Once she is done, the experienced developer should review her work. At that point, if improvements are suggested, both developers can compare the different approaches.

General guidelines

Like a football team, developers should have the same goals and work as a team. However, we also need to provide space for individual creativity. The best football teams win games not only because of their great teamwork but also because of their individual talent. A single individual play can change the whole game.

Some people work better in the morning. Others, like myself, work far better in the evenings. But it is important to have a time where the whole team is together, working in pairs. We recently agreed as a team to have our “pairing hours” from 10am to 5pm. This way, people can have some time alone either early in the morning or late in the afternoon.

By default, we prefer to work in pairs. We have no doubts about the benefits of pair programming. However, we also believe that providing space for individual creativity and learning is essential.