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.
The author tries really hard to suggest that when you work on a "code kata" you will not improve.
But there is no drill instructor yelling: "GIVE ME 100 CRUD-WEB APPS, RIGHT NOW!"
"code kata" is just a fancy name for a computational problem that has limited scope but still provides lots of room for creativity.
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)
I believe martial katas were invented as a means for one teacher to teach lots and lots of students at the same time. Like a lot of things of oriental origin, they tend to get romanticized in the west.
True, and also relevant: We solve so many different problems that changing the difficulty is only a start. Changing the actual task is as, if not more, important.
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.
"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.
There's got to be pretty much zero benefit in solving the same programming problem in the same way. However I have found considerable benefit in solving the same programming problem in different ways. So using different languages, programming different styles (I once wrote a program strictly following the Law of Demeter just to see), implemented a games rules system as a bunch of Command objects and then doing it again as a stack base DSL. This kind of "kata" (I join you in hating on the co-option of the word) has helped me expand my programming skill set.
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.
This kata concept has an interesting dovetail to Jennifer DeWalt's 180 Websites in 180 Days project[1]: repeated skills practice within a set of constraints.
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.
I also recommend codewars, it's a very well executed gamification of short programming challenges. I've been regularly solving problems on it for over a month and it's been a lot of fun. I had only written a few dozen lines of Javascript before I started; since then I have become much more proficient.
I practice kata every day. I typically show up to work 20 - 30 minutes early and pick a problem to work on. I record my answer for later reflection. Sometimes I will repeat a solution I came to before, sometimes I will refine an old approach, and other times I will think of a new way to approach it. I keep all of my problems that I collect and the solutions I come up with in a git repository.
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.
>I know I've improved when I notice in my journals that my language changes...
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 end up, "refactoring," by consequence of repetition I suppose. There are some days when I can't think of another way to write a fibonacci function (a trivial example... without including obfuscated methods, there are only so many effective ways to implement a function that computes the n-th number of the sequence). On those days I may end up calling to mind a previous solution and simply, "refactor it."
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.
I did something similar back in January 2012---I wrote the same program 30 different ways in four different languages (http://boston.conman.org/2012/01/09.1 is #1, just follow the links) and it was an interesting experience. Quite a few only differ in a few lines, or maybe cosmetically, but some versions forgo standard libraries, or read input in a radically different method, or explore different programming techniques.
I use katas to learn new languages [1], but I never do a kata twice. Picking a problem and solving it with a new language is pretty interesting, especially when you try it with very different paradigms.
Just to throw a slightly dissenting perspective ... I don't know, I've been interested in the concept of katas in a sense. I've done them a few times, but I always seem to have another side project (or three) that I'd rather spend my extracurricular time on. I guess if you have nothing else to work on katas are fine, but otherwise, just pour your time into a side-project that you're passionate about :)
Of course, that's just my viewpoint ... I understand it won't work for everyone. So YMMV
I've got a repo of some katas in Ruby on github: http://github.com/mark/katas ... they've definitely been useful for me to improve, and experiment with new ideas and new ways of solving the problem. I like problems which require a good mix of algorithms and "business logic".
I do katas every week and think they are great for both reinforcing good practice and helping you get over rough patches in your understanding of a language.
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.
Not necessarily like screenflow, but I have used Open Broadcaster ( http://obsproject.com/ ) for this purpose. All it does is recover various screen buffers to an mp4, but that is more than sufficient for this purpose in my opinion. Plus it is OSS.
Great for streaming video games to Twitch.tv or its variants, as well.
You could try LICEcap: http://www.cockos.com/licecap/, which is free for Windows and can produce an animated GIF. I haven't tried it for anything as long as 20 minutes, though.
It doesn't need to be long. In fact the point is that you don't need to solve the problem. You just get better at working on it. Short means you can do it often, and make it a habit.
That's a quite interesting concept, my way to do 'katas' is with projecteuler.net, now I'm getting some coding speed by reading a book about patterns or checking the wikipedia for software patterns. If you get to combine both, then sky is the limit!
PE has always struck me as more focused on math than programming. The easy problems handle brute force but the hard ones are generally bested by a mathematical understanding of the problem rather than programming prowess & algorithmic kung-fu. I've been meaning to check out Rosalind [1] to see if it opens up the door for more challenging programming or just shifts the problem domain to biology.
If project euler seems too "mathy" try some problems from Top Coder or similar programming challenges. I find they're pretty fun, and can be a bit of a puzzle to work out what's the most efficient approach.
I'm not saying that it's "too "mathy"", just that it's commonly trotted out as a good resource to develop programming skills when, IMHO, it's better suited to honing mathematical reasoning. All the single page programs in the world aren't really going to help somebody become better at writing real programs.
Repeating the task over and over again will reinforce good habits ( if you know the language well) and bad habits, if you are learning the language in the absence of a reference solution or someone more experienced to review your work.
A reference solution, "OK you did it - here's another way", would be super-useful for learning.
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.
The same place all employed people find time to do non-work related activities. Employed people play video games, watch TV, watch breaking bad, go to the gym, train for marathons, raise their kids, etc, etc. Your work is not an excuse for not being able to make time to do other things in your life.
If you're a lumberjack and your job is cutting down trees, when do you allocate time to sharpen the axe (or for that matter try out a newfangled chainsaw).
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.
I do them in my free time, like most. Oftentimes when I'm not cutting as much code as I want to at work (requirements gathering, meetings, etc) it makes me feel better to finish a little coding exercise (I like /r/dailyprogrammer) at night.
> if you can't measure it, how can you meaningfully improve?
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?
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.