Code katas are programming exercises intended to develop programming skills, analogous to the way katas develop martial art skills.
But literal katas are choreographed. They are rituals rather than problem-solving exercises. There may be an element of problem solving, such as figuring how to better execute the prescribed movements, but katas are rehearsal rather than improvisation.
CodeKata.com brings up the analogy to musical practice in the opening paragraph of the home page. But musical practice is also more ritual than problem-solving, at least for classical music. A musician might go through major and minor scales in all 12 keys, then maybe a chromatic scale over the range of the instrument, then two different whole-tone scales, etc.
A code kata would be more like a jazz musician improvising a different melody to the same chord changes every day. (Richie Cole would show off by improvising over the chord changes to Cherokee in all twelve keys. I don’t know whether this was a ritual for him or something he would pull out for performances.)
This brings up a couple questions. What would a more literal analog of katas look like for programming? Would these be useful?
I could imagine someone going through a prescribed sequence of keystrokes that exercise a set of software features that they wanted to keep top of mind, sorta like practicing penmanship by writing out a pangram.
This is admittedly a kind of an odd idea. It makes sense that the kinds of exercises programmers are interested in require problem solving rather than recall. But maybe it would appeal to some people.
Image “karate training” by Genista is licensed under CC BY-SA 2.0 .
6 thoughts on “Code katas taken more literally”
Agree that code katas aren’t really the same.
But I could imagine vi katas or emacs katas or vscode katas or rsutdio katas being useful, especially when trying to build muscle memory to more efficiently use tools like editors and IDE’s. And as examples of rote movements that non-the-less might inform novices of features of such tools they are not yet familiar with.
The closest thing I have to this are my set of shell one-liners I have committed to memory, primarily for bringing up embedded Linux systems on bare hardware.
They all live as shortcuts in my ~/.bash_aliases, but are more often used on systems where only root is available, before any users have been created. If it’s been a while, I will sometimes wipe an existing lab system, just to be sure my fingers still remember them.
This summer I began consolidating much of the R code I’ve written for my undergrad courses into R packages. After factoring much of the code into nice, generalized functions, I find that coding up all the assumption-checking has a definite, kata-like pattern. The pattern helps me keep the checks complete, with just enough variation to justify hand coding. At the next level of abstraction, the whole code/document-test-integrate-repackage cycle is another coding kata. I’m sure I’ll discover more.
The “Learn the hard way” books by Zed Shaw have the reader type in the code by hand as part of the learning process:
One way to practice is to think about writing coding something one is working on in another programming language. Is there a cleaner or more efficient or more expressive way to do this in Python or APL or C or SQL? I do this now and then, especially when my code is starting to get sprawly and clunky, as it often does after the initial growth spurt. Since different languages work best with different data structures, this can pay off in a big way.
P.S. The idea is NOT to do a literal translation. The goal is to express the algorithm as “naturally” as one can in another language.