Code Dojo
8 September 2009
On Thursday 17th September at 6pm there will be a Pythonic code dojo event taking place at Fry-IT’s offices.
So what on earth is a code dojo?
You could follow the link (above) to the nascent global code dojo site but, in summary, it is public collaborative coding with the aim of mutual learning based upon the premise that acquiring coding skill should be a continuous process. It seems that the original code dojo started in Paris sometime in 2005. (‘Dojo’ is a Japanese term roughly translated as “training hall” – often used when referring to martial arts or Zen Buddhism.)
A coding dojo will focus on a “kata” (another Japanese term meaning “form”). There can be two types of meeting:
- Prepared Kata – where a pre-agreed presenter demonstrates how to solve a specific challenge from scratch using test driven development (TDD) and baby-steps. Each step must be simple enough to be understood by everyone and the presenter should only be interrupted should this requirement not be met.
- Randori Kata – where a challenge is set and solved by pair programming (driver and co-pilot). Each pair has a small amount of time to advance the solution using TDD. When the time is up the driver goes back to the audience, the co-pilot becomes driver and one of the audience step up to be co-pilot.
We’re attempting a Randori Kata based meeting, but as none of us has ever organised a code dojo before, anything could happen (which is both a good and bad thing). I suspect the first part of the meeting will be to agree the ground rules followed the dojo itself.
We met a fortnight ago to agree a Kata and chose to create a pretty social network graph from Twitter data and Graphviz. I’ve built the “scaffolding” (available on GitHub) so we can jump right into the problem rather than worry about boilerplate code.
It’d be great to see you there…
3 Responses to "Code Dojo"
2009-09-18 12:30
Hey, thanks for organising.
I dug out the notes I made during the evening. I know we discussed most of these at the end of the night, but here they are in no particular order in case any of these are worth rolling into future events:
* It was brilliant. Thanks very much for doing all the donkey work of getting the scaffolding code together, and to Fry IT for hosting. There was much to learn, albeit that this first iteration most of that was about ‘how to run a dojo.’
* I know Nic took a quick straw poll of people’s familiarity with various operating systems. From your vantange point at the front, what were your impressions of the results of that? I remember thinking that Windows got a very poor showing. I am no fan of Windows, and yet I wonder how many people failed to put their hand up for it merely because they don’t like it, rather than actually not being familiar with it. I wonder if it might not be a suitable lowest-common-denominator environment that most people have at some point used.
* Available of at least one plain old vanilla editor (eg. TextPad, GEdit, etc.) I talked to one person at least who was intimidated from participation because they don’t use vi nor emacs.
* Availability of a regular keyboard might smooth one or two wrinkles. I don’t know whether the phrase ‘regular keyboard’ means anything in Mac circles. Does it?
* TDD is hard to get started at the outset of any project. I wonder if we might ease the initial stage of the dojo by starting with written stories that could be translated into tests, and maybe even starting out with a single failing test.
* API and code design is hard, and people are flustered. People felt pressured to produce visible progress, and to attain our stated goal by the end of the evening, and in the rush we all skipped an amount of refactoring, and of proper process. I feel like these are actually more important to include in the dojo than the completion of any particular problem. Ideally, of course, the problem should be simple enough that we can complete it AND refactor nicely AND use good process. Failing that though, my feeling is that the process and refactoring are more important than the completion.
* With hindsight, I felt like in our exercise last night, I would have liked to make a clearer distinction made between our functional tests (if any) which genuinely will interface with the outside world (eg. the twitter API), and our unit tests, which will not and should pass fine even if, for example, we have no internet connectivity.
Make any sense?
2009-09-18 12:37
Hey Jonathan,
All very good points… and I think I got most of them (in some shape or form) in the more recent post-mortem post. ;-)
Your post makes absolute sense.
2010-02-19 15:38
I want to tell that an experienced classification essay service seems a light on the path of sample essay composing. So, people are able use it anytime they want buy custom essay.