Went to the advertised London Python Code Dojo last night. Not quite sure what to expect (altho’ Nicholas Tollervey, the front man, had done a readable write-up beforehand). It was great. About 30 people, some faces familiar to me from previous London Python meetups, others not. Beer & Pizza kindly supplied by the hosts, Fry-IT.

Altho’ a few people had attended other code dojos before, most of us were first-timers so there was an amount of feeling-the-way going on. Nicholas hooked his Mac up to a projector (with *both* kinds of editor available :) ) and people came up in pairs to code — pilot and co-pilot — for 10 minutes before handing over to a new co-pilot with the old co-pilot taking over the controls. The target app was a GraphViz graph of Twitter contacts, so the first 5 minutes was spent simply trying to set up a Twitter account with a name and email address which had not already been used!

Altho’ there were small issues — people using an unfamiliar environment, keyboard, editor etc — the 10 minute turnaround on each pair created a dynamism which kept the thing active. There is, apparently, an alternative approach where one guy stands at the front and talks through what he’s doing, but that doesn’t seem to me to have the same appeal.

There were several suggestions at the end as to what might be improved. The scaffolding code which Nicholas had already put in place to generate graphs given an edge-list was ideal since it made it feasible to actually create a solution within the 2 hours we were working. But some people thought more time was spent learning the Twitter API than was really useful. For my part I didn’t have a problem with that: it’s all part of the learning experience. The size of the group meant that people at the back of the room were less engaged. There were suggestions of two parallel groups competing, but I think it was decided to hold off till later on that.

What was interesting from my perspective was the way that different people approached the — admittedly loosely-specified — problem. There was an unspoken assumption that test-driven development was de rigueur, a discipline I don’t entirely share but am happy to go along with. What surprised me the most was that no-one fired up the interpreter to see what the Twitter API was doing. There were tests being written without (I think) knowing what the API was going to return. I’d just have started the interpreter, logged on, and retrieved a list of friends — or whatever — to see what I was getting back. But everyone’s different.

I don’t know if this is the idea, but one thing you do get is a kind of audience participation effect. Altho’ you have the pilot & co-pilot up front, verbalising their thought processes, you have a room full of back-seat drivers all giving advice at different times. Vastly entertaining.

Just a couple of suggestions from the point of view of a big group: maybe have the pilot / co-pilot hooked up to head-mics pushed through speakers; and have a slave laptop at the far end, projecting a VNC Viewer of the master onto a nearer screen/wall so people can see/hear what’s going on.

[I was the final co-pilot, for those who don’t know me :) ]