This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

×

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

×

Pair Programming

For those that have never experienced this (and I wholeheartedly suggest you do), it is where two programmers work on the same code at the same time at the same terminal. One of the pair acts as the pilot, operating the keyboard, whilst the second person plays the role of navigator. At first glance this seems counter intuitive that two people doing what is normally done by one can be any more efficient. Although difficult to quantify it does appear that it is. What must be remembered is that by pair programming you do away with a separate code review phase, and also benefit from knowledge transfer. For more information try the following Wikipedia article.

Good pair programming comes to resembles a conversation with both programmers actively involved in the design.

In my time pair programming I have found the following useful:

  • When pairing with a more junior developer, I find it is better to allow your partner to drive, this seems to keep them more engaged, and allows you to guide them, of course always in a constructive and supportive manner.
  • Resist the temptation to “pair separately”. This is an “anti pattern” that can creep into pair programming for any number of reasons, but usually due to inexperience or time pressure. The pair separates to work on the same task but at different terminals (sometimes different laptops on the same desk).
  • Try not to let the pairs become fixed. It is quite easy for pairs to stay together for extended periods (e.g. an entire story card, or iteration) for various reasons, interest in the task, their desire to work with a known quantity etc. By not rotating the pairs frequently you lose the benefit of the knowledge transfer.