Pair Programming: a few thoughts

I recently read a great article on pair programming by a developer over at Atlassian where he really summed up my views on the topic. I have had really good experiences with pairing and some not so good ones.

What came out of some of the more positive experiences were:

  • I came up to speed on a new system quickly
  • Risks or major design questions were verbalised and dealt with sooner
  • I learnt more efficient ways of coding things
  • I learnt more cool eclipse keyboard shortcuts!
  • My TDD and general development skills rapidly increased

Some of the more difficult experiences:

  • I felt frustrated at the sometimes slow pace
  • Sometimes my pair would dominate the keyboard so it was easy to drift off into la la land
  • When joining an existing team I worried I wasn’t learning enough of the system and if they were sick that day I’d be lost

Some of the paring experiences Ive had I didn’t realise until much later how extremely valuable they really were.

I think in order for pairing to be successful you should:

  • rotate partners often
  • be open to constructive criticism on code improvements
  • voice your opinion/suggestions so you can work a team to develop a solution
  • take breaks every couple of hours to check email/facebook – refresh
  • ensure you get equal keyboard time
  • keep trying! – pairing wont come naturally to everyone but there are a lot of benefits to come out of it and its a chance to really improve as a developer

If your workplace doesn’t see the value in pairing then as stated in the article, I think the next best thing is to make sure you get an extra set of eyes on every line of code committed, whether its using a code review tool or as I did on a former project, have another developer check over your code before each commit.