The Coding Dojo: My First Time

So there it was, my first time.. A little scary, a little intimidating and seemed to be over in a flash..

I just got back from my first ever Coding Dojo. In short, a coding dojo is:

A meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in deliberate practice in order to improve their skills.

“Deliberate Practice”?

Deliberate practice is basically making sure you do things right rather than doing them to get the work done. When at work, we often need to be pragmatic and cut certain corners in order to meet deadlines/budgetary requirements and all the other crap that actually comes with writing software for the real world.

This often means that some practices may be neglected. Coding dojo’s aim to put us in an environment where we can work to those practices, improve them and then integrate them into our working processes (at much lower cost).

My First Experience

The problem we were trying to face was simulating the numbers round from the Countdown TV Show. Now, the code to generate the numbers that represent the problem was completed in a previous dojo, so we were tasking with creating the solver.

First off, wow.. This is actually a pretty tough problem! Here are my thoughts:

Deliberate Practice

Seemed to pretty much go out the window.. We found ourselves running down the rabbit hole rather than stepping back, re-evaluating and then writing appropriate tests. There seemed to be a hell of a lot more code in “production” rather than in tests – and one thing I have found is that when TDD-ing at work/home, my test code is normally about twice the size of my production code.

This became painfully obvious as we kept running up against roadblocks – TDD aims to overcome this by always solving the simplest problem next. I will say however is that conceptually the numbers round is a simple problem, but the logic process is actually kinda difficult to unwind.

Red > Green > Refactor

TDD-er’s out there live and breathe this. Before writing production code, there must be a failing test. We then get the test to pass. Finally, we refactor the code (and test code) ensuring we do not break the tests. Rinse and repeat until your code is done.

Put bluntly, we were absolutely crap at honouring this! I think it would probably be best to have someone nominated as “overseer” or “Uncle Bob” who is there to beat you with a stick when you don’t stick to the plan.

The Lovely Hotseat

It was amazing to see how much input people gave, and then froze up when the keyboard came to them. I personally found it a very interesting experience. Much like giving a presentation, simple things suddenly become much more difficult when all eyes are on you. This is probably something only experience will overcome – but it’s definitely a roadblock. I think having a chance to build rapport with the group will help also.

Summary Thoughts

Overall, a good session – but I think the format (or at least the way we implement it) needs some work.

Honestly though, I found the single most powerful positive from it was simply sitting down with a bunch of other passionate developers and chewing the fat on a problem. IMO a “good” developer will eventually come across new practices and always work on improving their “A-game” due to the natural inquisitiveness of our nerdy breed. :)

However, the ability to problem solve and look at things from a wide variety of angles can be VERY difficult to hone. Having someone else there to just throw it in your face makes the process a whole lot easier!

On the whole, a positive experience. A few (expected) teething issues but nothing that makes me feel bad about it. Looking forward to attending another soon!

Obviously, the above is based on extremely limited experience. So as a reader, I would take it with a pinch of salt. I am always a fan of “don’t take my word for it” – find out for yourself!

Things I Would Like to See

• Ideas/spikes before and after the dojo, checked in to a shared repository to spark discussion to get the ball rolling quicker.
• More talking from the person in the hotseat and more listening from the spectators.
• Planning before the keyboard gets to you, perhaps writing ideas for tests, or working with your partner on tackling an implementation segment together.
• Stricter adherence to the “deliberate practice” principle.
• Somehow sharing code across machines and allowing developers to use their own environment.. I really missed all my snippets/key configs etc. Provided you are working to agreed code standard, it seems silly to deprive a developer of what feels right for them. The speed at which Git (and other DVCS’) can commit/pull/merge should make this easy.

Have you ever been in one or more coding dojo’s? What are your experiences/thoughts?

Work hard, play harder.