In the spirit of one of our core values, #AlwaysBeLearning, MarketFinance has teamed up with continuous delivery thought leader, Dave Farley, on a series of Tech Blogs. Our engineers have asked Dave a few burning questions about everything from pair programming and trunk based development to continuous delivery and more. This week’s question comes from Senior Software Engineer, Mason L’Amy:

“Pair programming has been shown to increase quality and reduce overall development time. Nevertheless, some people need heads-down focused time on a problem. How do you balance this?”

My preference is to strongly encourage teams to adopt the norm that most work will be done working in pairs, but not to make it a rule. I think it right to leave room for people to decide for themselves when it doesn’t make sense.

However, you are right, ALL of the data that I have seen from studies of pair programming say that it produces higher-quality output, and so in the long run, is significantly more efficient in delivering new code. More than that, I know of no better way to encourage collaboration, learning and continual improvement in a team than pair programming.

So it is strongly in a team’s interest to adopt and encourage pair programming as the norm. It is not good enough to reject it because some people don’t like it. That would be like mountain rescue teams rejecting the use of ropes because it is annoying to carry them up the hill. Some things have value even if they take some work.

For me, this means that it is worth some effort, maybe even significant effort, for a team to adopt, learn and make pair programming a fundamental part of their development culture.

My experience has been that most people, before they have experienced it, are nervous of pairing. In part I think that this is a cultural thing, we “program” people to imagine software development as a lonely introspective act. I don’t think that good software development is really like that. It is, at its heart, a process of learning.

We learn best when we can try out new ideas and quickly discard the bad ones. One way to test ideas is to bounce them off another person. So pair programming provides us with a mechanism to quickly and cheaply exercise ideas and weed out some of the bad ones.

There are also some individuals who will always find pair programming stressful. If I am honest, I believe that these individuals have a more limited value to the team. They may have value, but that value can’t be as much as someone of similar skill who learns faster and teaches more.

Introverted people are more sensitive to stimulation than others, and so need more quiet time to reduce the cognitive clutter. I am one of these people. I need, periodically, to be on my own to organise my thoughts. This doesn’t mean that people like this can’t take part in pair programming, it does mean that you have to give them some space, some of the time.

So, my idea of “optimal” is to do most, nearly all, development work in pairs but allow humans to be human. If someone needs time to form their thoughts, or learn some tricky concept alone, or just needs some quiet time to recharge for a bit, give them that time.

There is another important aspect to this. There is some skill to pair programming. It takes time to learn some of the social aspects. For example, one very common behaviour that I see, in newbies, is for my pair, when I am typing, telling me letter-by-letter when I make a typo or what the instruction is. They are trying to be helpful, but they are not.

Watch your own typing for a bit. If you are anything like me, then your typing will progress forwards and backwards as you make little mistakes and then correct them all of the time. When this happens you know, as you type, that you made a mistake. Most errors you corrected immediately. Someone telling you at this point, actually slows you down. It interrupts the flow of your thinking – and it is irritating.

So when you are pairing, and you are not typing, give people a chance to spot, and correct, their own mistakes. Only mention a typo when the typist has moved on and clearly missed it. Only mention the correct use of a language construct or api call if the typist is clearly stuck. Otherwise KEEP QUIET!

The classic description of the roles in pair programming are “Driver” (the person who is typing) and “Navigator” (the person who is not). This is a bit crude, but close. If you aren’t typing your focus should be on the direction of the design rather than the typing.

The other important aspect of pair programming as a learning activity is to regularly rotate the pairs. Change pairs often, don’t allow pairs to become stale. My preference is to change pairs every day.

This sounds extreme to some people. It means that nearly everyone works on nearly everything that the team produces over the period of a week or two. It means that you get to see different people’s styles of working (and pairing) and learn from them. It means that you get to work with the person on the team that you find trickiest to pair with and with the person that you enjoy working with the most, on a regular basis.

Pairing means that you are working in very close proximity to other people. Think of your pair as a team, you have shared goals and will succeed, or fail, together. Be considerate, be collaborative, be kind!

If you get this kind of stuff right, then the barriers to pair programming begin to reduce. Even the introverts on your team will not only take part, but will benefit from it. Pair programming takes time to adjust to. This is not something that you can try for a day or two. It takes a while for a team to get really good at it, so allow yourselves the time, don’t give up too soon.

Dave Farley is a thought leader in the field of continuous delivery, devops and software development in general. He is co-author of the Jolt-award winning book ‘Continuous Delivery’ as well as a regular conference speaker and blogger. An early adopter of agile development techniques, Dave has been employing iterative development, continuous integration and significant levels of automated testing on commercial projects since the early 1990s. Today, he is the founder and MD of Continuous Delivery Ltd where he works as an independent Software Consultant.