Stok Footage

Continually experimenting with new ideas and techniques — Reconstructing, Developing, Modernising.

Adventures in Pair Programming (Part 3)

Time is passing, and my pair programming presentation at the Toronto Perl Mongers is looming. So it’s time to do some more preparation…

Today I had a friend over to try some pair programming. I wanted to attack a simple problem so we could focus on the mechanics of pair programming without being too distracted by the problem itself. Some of the things I wanted to try included:

  • One keyboard / screen / mouse.
  • Pomodoro time management so we made sure we swapped rôles.
  • A real attempt to do Test Driven Design, where we let the error messages guide us and didn’t let the temptation to code wildly seduce us.
  • A real attempt at the red / green / refactor cycle, so we could make it work and then make it right.

The experience was positive. Very positive! As I work as part of a dispersed team it was a delight for coding to become a fun, social activity.

I didn’t quite succeed at the one keyboard / screen / mouse — we used a laptop with an external display, and a USB keyboard and mouse. For most of the time we were doing pair programming, and occasionally the “non-driver” would use the other keyboard to look something up. For the bulk of the time both of our attention was on the shared screen.

The Pomodoro time management worked well, a chance to get up and walk around, get away from the computer and let our subconscious minds kick in worked. We used the interruption to change rôles, and we were pretty good at stopping when the timer went off — if a test was failing then it would remind us where to pick up (particularly after lunch at the House on Parliament).

TDD worked well, we did discuss things a couple of steps into the future and yet managed to focus on failing tests and doing one step at a time. This lead to discussions about possible ways to continue and every error seemed to open up possibilities rather than be a blocker. It was reassuring to do things in small steps because we were never far from a working state. Several names got changed as we discussed what was being written, and saw how the tests communicated (or failed to communicate) the intent of the code we were testing.

The red / green / refactor cycle was useful because it reduced distraction. We could make it work and then rearrange code in the refactor phase. This was the first time I had had a partner to do refactoring with, and the discussions about where stuff belonged and what it should be called were fun and useful.

There were other benefits too. We shared information about tools which we had used, when I couldn’t explain Ruby namespacing then I realised I had to do some learning myself. “Failing” in this environment was a learning opportunity.

In conclusion… What a great day. Good research for my talk, good progress on a project, and a very satisfying day. Thanks to Stuart Watt, my partner in pairing!

Background: The problem is how to iterate over an IO stream which contains a tar file in an idiomatic Ruby way. This will fix a problem at #{work}, but I’d like to enjoy it so I’ll do it on my own time. If you care, the work is on GitHub.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.