The Merriam-Webster dictionary provides the following definition for kata

a set combination of positions and movements (as in karate) performed as an exercise

Most people are probably familiar with katas as they are used in martial arts (come on, admit it, you liked the Karate Kid).  My introduction to katas in software was through the Software Craftsmanship movement, where they are often used as training exercises.

It is important to understand with coding katas that the idea is not to do the exercises the same way every time.  Katas are a great way to experiment with different techniques and styles.

• Can I provide more descriptive naming
• Does a terse syntax make the code easier or harder to understand in a particular place.  Would a more verbose, explicit approach be better.  For example, in the case of a complex ternary operator, would an explicit structured if/else construct be better?  Worse?  Try them out and decide for yourself.
• Experiment with different syntax, e.g. the unless keyword in Ruby.  More or less readable?
• Should I use a defensive programming style checking for nil/null in several places or a more confident programming style?
• How am I naming my tests (yes you should be writing tests as part of your katas)

There are no right or wrong answers to these questions, the goal is to experiment and try out new ideas.  Understand where an idea works well and where it doesn’t work well.  Try a variety of approaches.  And the great thing about a kata, unlike your code base at your real job, is that you can blow it away when you are done and do it a little different the next time.

Katas and Interviews

I’ve been using pairing as a key part of the interview process for several years now, but a consistent challenge is to what to pair on.  It is unrealistic to assume that most developers are going to walk in the door and instantly grok your code base.  No matter how awesome you are or how descriptive the tests are, it’s just not gonna happen. Instead pick a problem set that a candidate can quickly get their head around and that you can discuss different design and implementation choices.

Katas and Pairing

I had an awesome pairing session yesterday with someone I had never worked with before, and we did some katas as a way to get to know one another, discuss approaches to coding, good naming, refactoring techniques.  It was a blast!

And the really great thing about katas and pairing is that it can be challenging to think of different ways to try something on your own.  But with a pair you have different perspectives baked-in.  And what you can learn may not be strictly code related: it could be keyboard shortcuts, different IDEs or editors, maybe even a wacky keyboard.  Don’t be afraid to experiment.

Resources for Katas

Cyber Dojo Great resource for ideas for simple exercises.  Even if you don’t use the online collaboration tools, it has a great list of problems that can be used for a kata.  I used this yesterday for my leap year kata in Ruby

Dave Thomas’s Katas This is the blog post that kicked off a lot of the talk about katas in the software craftsmanship movement. Again, great problem sets that you can get your head around quickly, but with enough meat for some interesting challenges to address.

Your Friendly Neighborhood Software Craftsmanship Group Here in Boston we have Boston Software Craftsmanship. Great group, someone’s always willing to pair.  Find your local group, or start one yourself.

Another Developer on Your Team Ask someone on your team if they’d be interested in brown bagging it some day and do some kata’s together.  You should do this especially if you are not pairing now or are not doing TDD.  You may find that you should really be pairing and you really should be doing TDD.  You should.  Really.

CodeRetreat.org I had a great time at last year’s Global Day of Code Retreat.  Check it out.  Conway’s Game of Life is a great coding exercise.  This also introduces some great constraints and pairing ideas that really get you thinking.

Now get out there and start coding…