support Corey Haines

For nine months now Corey Haines has been travelling around the Eastern US as a journeyman programmer. During that time he has run numerous code retreats, published numerous fantastic interviews with leading developers, and made dozens of blog posts and videos in which he reflects on the things he’s learned from the people he’s paired with. The body of Corey’s travails is already beginning to form an invaluable reference, and all of the insights he has pushed into the public domain add to our collective knowledge about how to develop software carefully (in both senses of the word).

Just as amazing as the project’s knowledge elicitation is the fact that Corey is self-funded. He pair programs for food and lodging, and just by doing that he has given back an enormous amount to the community. Well, now he’s skint. The journey will continue only if Corey can raise some funds.

So please visit Corey’s blog and pledge a few quid to keep the journeyman on the road. I did, and it didn’t hurt a bit.

And next year, Corey, how about we raise the cash to get you over to the UK for a tour?

Advertisements

learning by driving

I’ve recently been TDD-ing on a project in which I had to very quickly come to understand a lot of new technology (libraries, development tools, target environment, patterns, techniques). Pair programming with a local expert was the natural approach, but it wasn’t working particularly well until I started doing the driving. I did learn a little while my partner (the expert) had the keyboard, but it’s not easy staying alert and focussed when you understand very little of what is happening. On the other hand, as the driver I was much more engaged; and my partner was perforce more engaged in helping me understand. I’m sure it must have been frustrating for him having to tell me even the simplest stuff, but after only a short time I found I was able to contribute more and more to the task. I’m still a long way behind my partner’s expertise, and yet I feel we can now work reasonably effectively as a pair.

I’ll try to remember this next time I’m the one with the knowledge: let the novice learn by driving.

a second pair of eyes

I’ve just been working with a team which has a pairing policy: every item of code must have been seen by two pairs of eyes before it can be checked in. It doesn’t work.

The effect of the policy is to replace pair programming – instead developers do a “pair check-in” at the end of each development episode. So a developer will beaver away working on a feature for a day or so, getting it right, making it work, passing all the tests. And then he’ll call over to another team member to request a “pair check-in”. The other team member comes to the developer’s station and is walked through the changes in the version control tool. And then the code is checked in and the two team members part company again.

The problem here is that the process sets the two people up to be in opposition: the developer is effectively asking for approval, instead of asking for help. It’s natural for the developer to feel a sense of ownership, because he’s worked hard to get that code complete and correct. Not many people can graciously accept negative feedback after all that hard work.

It can also be hard for the reviewer – the “second pair of eyes” – to come up to speed quickly enough. The developer knows these changes intimately, but the reviewer is being asked to understand them cold. He has little chance of being effective in that situation.

So this process has all of the demerits of Inspections, with none of the advantages. The team would be more effective adopting true pair programming, I feel.