Recently I was introduced to the London Code Dojo by a good friend and on Monday I attended my first code dojo!
What is the Code Dojo?
A dojo is a place to practice an art and a code dojo is no different! The purpose of it is to allow developers to practice and learn. The first rule of code dojo is you are there to "do it right"!
Everyone has probably heard it takes practice to make perfect and in theory you need to do 10,000 hours of practice to become an expert in anything! This practice has to be done properly though, specifically it must:
- Be focussed
- Be goal-Directed
- Be stretching (aka not easy)
- Include continuous feedback
- Include self-reflection
- The goal is to do things correctly, not to simply get everything done.
- You must do Test-Driven Development (this is taken to the extreme)
- You must do pair programming
- You must commit/revert every 5 minutes!
- Commits must be meaningful with a simple and descriptive one-line comment.
- After 20 minutes a quick retrospective is held and new requirements maybe added.
My Impressions & Lessons Learnt
Our Kata for the night revolved around implementing Fizz Buzz, which is non-trivial given the TDD constraints.
The dojo really gave me a baptism of fire. As no one wanted to write in Java, I took it upon myself to try to code in Scala for the very first time. Simply reading the Scala chapter in my book club book had given me a decent start though :) Apologies to my pairing partners for the frustration!
@sleepyfox who runs the dojo made a great pitch for TDD and how it saves time in developing long AND short projects! From my point of view, I suppose it follows the whole "fail fast" methodology. Mistakes are always made and by doing TDD you ensure you catch mistakes quickly, rather than having to hunt for them.
However I still reckon the age old "it depends" answer applies to whether or not you should use TDD. Part of my 'homework' is to research "Spike and Stabilise" which sounds interesting...
One thing I did get pulled up on was my when I answered too quickly. Remember: "Respond don't react!". Polymorphism is not necessarily always the answer to replacing a bunch of "if - instanceof" statements!
My favourite phrase for the evening was: "If you are 'refactoring' but everything ends up broken, you are actually 'ref**ktoring' your code" XD
The biggest takeaway was the emphasis on ALWAYS being simple, concise and expressive. Doing things in a complicated fashion is easy, any idiot can do it. But being simple is tough, in both your code and your commit comments.
Really learnt a lot from the dojo and look forward to future ones!
No comments:
Post a Comment