Last month we had another team code competition, this time centered around writing code that trys to solve a maze. Clojure seems quite apt for creating these kind of challenges as it has a lot of support for dynamic code evaluation and the functional paradigm makes writing callbacks a lot easier.
Just like the Battleships dojo it was interesting in that the random strategy was a good local maximum. However one revalation that the maze wasn’t cyclic later then left-wall hugging was kicking everyone ass. That then left dead-end elimination as the only possible way to produce a faster solver. Which our team failed to do sadly. Right idea, wrong turning table.
We also got bogged down on a Clojure issue which has come up a few times at the dojo. I’ll summarise it here: should you be using Clojure 1.4? Your library syntax and server compatibility depends on the answer to this and there is no good error message that is going to tell you that the language syntax has changed.
The competitive dojo is an interesting environment where only the best work process and most pragmatic code can thrive. It is an interesting critique of hammock-style as the result of all thinking and beard-stroking better be order of magntiudes better than the obvious answer.
We also got to see a good example of beard-stroking abstraction this month with Chris Ford’s introduction to the theory of music and its abstractions in a general purpose computing language. An amazing talk which combined education with an amazing abstraction over music itself.
Echo One 
It turns out that it doesn’t even matter if the maze is cyclic as long as you know that the starting position is in the top left and the finish is in the bottom right (and that there is a wall round the outside of the maze). In that case, you just need to make sure that you hug an exterior wall and you’ll be guaranteed to reach the finish eventually.
You’re definitely right that the dojo is an interesting environment. I think that the main lesson to take away from this and previous dojos is to Keep It Simple (Stupid); you’re probably not going to get much code written so any grandiose plans are unlikely to be completed; better to stick with something that you can do in the time.