Using Katas to Improve Your Coding
blog.8thlight.com
blog.8thlight.com
tl;dr: doing the same thing repetitively only improves your skill to a point after which you need to increase the difficulty of the task if you are to continue to improve.
More than just a counterpoint, it has even more insight & useful suggestions than the OP.
For those interested in this subject, make sure to check out this link, too.
Coming from a martial arts background, kata are about learning very specific motions -- more than one at a time -- by performing them repeatedly in sequence. This does not mean that kata are an end in and of themselves. They teach you what to do, not why to do it. They train your body to do something. The why comes later, when you have the how as a basis; this is a fairly fundamental difference between learning a physical skill and a mental one, where the latter can be mastered without at least some of the conditioning necessary for the former.
Doing the same thing in code will train you to solve a single problem, whether in one way or in more than one way, and the difference really doesn't matter. It's trivially different from training you to solve problems, which is what good programmers do as a matter of course.
Effective ways of improving skill x are not necessarily applicable to learning skill y. I believe this is one instance of x and y being so far removed from one another as to be totally unrelated, and the application of training methods for x just don't matter at all for y; one man's garbage is another man's treasure, and this to me epitomizes that.
Well said.
ime, people who try to 'exoticize' their programming by abusing martial arts/zen/taoism etc terminology never seriously practiced a martial art (or zen or taoism for that matter) in their lives.
In the martial arts, playing an instrument, etc you are improving body movement/memory which does take repetition and hence you need katas/etudes. The value of repeating the same problem in a mental activity like programming or math (imagine writing the same proof a hundred times) is dubious. Which is why so called "kata" often degenerates into optimizing the physical components - learning key combinations on an IDE/editor (which has some value, but can probably be undertaken without the martial arts mumbo jumbo). Timing a "kata" just adds to the craziness.
Andrew Dalke tangentially takes apart "Uncle" Bob's Prime Factors "kata" here (while skewering the "TDD as design" idea as the main focus) at http://www.dalkescientific.com/writings/diary/archive/2009/1... .
"code kata" is just a fancy name for a computational problem that has limited scope but still provides lots of room for creativity.
Just like a the questions on https://projecteuler.net/ but with a lesser focus on number theory.
tl;dr: "code katas" were never intended to be mindlessly repeated but to deliberately think about what can be faster, better, more elegant, expressive (name you favorite)
see: http://codekata.pragprog.com/codekata/2007/01/code_katahow_i...
Just doing something isn't going to improve your skill; doing it mindfully and being aware of what you're doing, why, and how you could do it better will improve your skill.
To use his analogy -- walking every day won't help you be a better walker. But being aware of how you walk and how you respond to obstacles and improving your reactions will.
I really like Chong Kim's idea of using Screenflow to capture these sessions and be able to review them later, played back at high speed. The opportunity to "look over my own shoulder" as I'm working a problem, to inspect my workflow in a manner detached from the moment, seems like an invaluable training tool. Video review has been used for athletes to improve their skills for ages now, and has become very accessible right along with smartphones. Applying those techniques to coding or other knowledge worker skills (work in Photoshop, etc?) is pretty darn interesting.
[1] Most recently on HN at: https://news.ycombinator.com/item?id=6489468
Sometimes I will call to mind an interesting solution I came up with. Having the repository is handy so that I can pull up the problem, the solution I am interested in and perhaps diff it against a previous, similar solution I had came up with before. I use this time to reflect on the changes I made, how it changes the characteristics of the algorithm (time, space, bounds, etc), and whether it states the intent with more clarity than before. I keep these reflections in a journal.
I know I've improved when I notice in my journals that my language changes dramatically from dense, technical language to simple, straight-forward language without losing any of the accumulated knowledge.
While what you're doing is admirable--I wish more developers did this--the central question is not whether you improved, but whether you improved more than if you'd done other work. For example, learning a new language, refactoring, etc.
I have conflicting feelings about learning new languages. I do it every now and again but for a craftsperson I don't feel that it is the ideal approach. As some monks I've heard say so it is with programming: you can be fluent in many languages but master none. Real mastery requires dedication and focus over time. But that's not the whole story, is it?
I've met too many developers who will put C on their resume under the assumption that they are capable of writing C programs. More often than not it's a bold-faced lie, but when it isn't I find they are certainly capable of writing a C program and getting something to compile. However there are very few who understand what sequence points are, that still treat the linker like black magic, and don't fully grasp how array and array pointer parameters are changed by the compiler.
The point I'm getting at is that C is generally one of many languages on a programmer's resume. And it's usually an after-thought. However if you really grill someone on the soup-to-nuts of just one of these languages you can find holes in their knowledge. They learn enough to get something useful done but they don't know enough to do truly masterful things with the language. I think about it like being a musician: you can learn enough about an instrument to join a jam but to push the boundaries you need to master one. And mastery is something I find thats consistent, dedicated practice.
As to how to measure whether I could have improved more if I had done something else other than master one thing... I think there's a lack of bounds there that should be determined by your goals. If your goal is to join a jam and play along then you want to learn as little as possible up front and as much as you can as you go along. I think this is the par for modern programmers these days. But if your goal is to push what's possible with a particular instrument then generalizing your knowledge is not nearly as effective as studying music with that instrument alone. Both are valid approaches and it's a matter of limiting the scope of possibilities based on what you want to achieve.
Though mastery tends towards an asymptotic function reaching, but never achieving, perfection.
Of course, that's just my viewpoint ... I understand it won't work for everyone. So YMMV
That said there are quite a few katas out there that are either trivial or merely puzzles to solve. The former are great for beginners but pointless for anyone else. The latter are fine if you are doing them for the same reasons you would do a crossword puzzle but they are probably better avoided if your goals are more practically oriented. The hard part is wading through the chaff to get to the wheat.
I've been practicing on TalentBuddy and really like it. It nicely supports lots of languages, and you can check your solution against others.
www.talentbuddy.co/
Great for streaming video games to Twitch.tv or its variants, as well.
I know that I can complete most any kata, but I don't always know if I'm doing it the most efficient way under constraints of implementation time, memory or speed.
Early in my career, I too worried about "unrelated" personal research or development. I'm at the point now that I'm fully comfortable with the fact that you have to go off and do unrelated / indirect work to maintain a high overall productivity - this is a fundamental part of the expertise for which you are being paid. Some employers are better about formally supporting and/or directing that development. But even if they don't formally do anything, allocating a judicious portion of your time to self-improvement falls in line with your self-interest as well as your employers interest. This includes time at work.
The idea that you must have a quantitative measure to improve something is a bit overboard. Process analysis can teach you a lot about how you (or others) work, what the character of that work is, and suggest ways to improve it. For example, Kim's Screenflow session captures can be viewed as a kind of Contextual Interview[1] ... with himself! In that light, the primary goal could be viewed as one of discovery: "how do I work?" versus "how do I improve metric X in my work?" The initial Kata review may suggest metrics for improvement, but it's the continual process of open-minded review that will identify and suggest areas for improvement.
That said, Chong Kim does cite a key metric: time. So on that point, he's looking to optimize his efficiency with the tools. There's a lot to be said for just time efficiency; improving this can be a very liberating experience as a coder. Speaking from experience with contextual interviews done for others, it's often possible to significantly improve workflow by just hitting the proverbial low hanging fruit.
That said, time isn't the be-all, end-all IMO. In the Katas, I'll argue for time as a model which provides structure to that more important inquiry I cited above: what is his working process and learning process for each new problem domain? How can those be improved?