Wikipedia credits Dave Thomas with the idea behind code katas. Short exercises designed to improve coding and code design skills.
It feels a bit trite to define code. For the purposes of a kata we are talking text that is either interpreted or compiled into an executable and then run.
Kata (型 or 形 literally: "form"?) is a Japanese word describing detailed choreographed patterns of movements practised either solo or in pairs. The term form is used for the corresponding concept in non-Japanese martial arts in general. http://en.wikipedia.org/wiki/Kata
Ninja in western culture and perhaps beyond has come to mean someone who is highly skilled. It is also a really cool domain name.
If practice makes perfect then performing code katas improves your code and coding skills. http://codekata.com has a good description of what a Code Kata is and a list of Katas for you to try yourself.
Katas can be done by yourself as a way to hone your skills in private or you can participate in a Coding Dojo and use Code Katas in a group setting. Emily Bache has written a book all about running a Dojo The Coding Dojo Handbook that you might find interesting.
Performing Code Katas is about improvement. Like a musician or someone who plays sports its about taking some element of the activity and practicing it in isolation to improve that one part. By repeating these practice sessions your overall game improves. You might want to improve your TDD skills, learn a new programming language or try different designs against the same problem. Refactoring is about improving code design without changing behaviour. You need tests to move with confidence but working on small programming prolems (katas) you ability to spot refacotring opportunities improves.
The problem domain often favours a particular programming style or language. Repeating a Kata using different designs and languages helps you improve your ability to make better choices with larger problems.
Kata problems are designed to be short or can be split into chunks of time and performed over a longer period or on differnt occasions. I typically budget about an hour which includes setup, working on the problem and then reflecting on how I thought the exercise went. Don't skimp on the reflection part. Take notes to review later, areas to work on next time. If you are pair programming (highly recommenced) then discuss the problem with your partner.
Choose tools that are either appropriate for the chosen language or that you want to learn. If you are paring then make sure that the ground rules are agreed. Emacs/Vim debates are fun but should not be part of the kata.
Time taken setting up for practice can be a time sink. During my practice sessions I found myself spending too much time setting up a basic project template and then switching back and forth between editing and running my tests.
lazybuilder helps with the second problem. It waits for changes in the source tree and triggers a build/test run of your code. codekata installs and runs lazybuilder.
Both of these tools are OS X only at the moment. If you are interested in porting them to another platform feel free to get in touch or send me a pull request.