I've caught up with a friend of mine over at FiniteAttentionSpan and the subject of Taekwondo came up. There are some quite evocative images and lessons learnt there, that can be applied to other situations in life. I trained for about 6 years and it's been a rocky ride. Now I'm older, I look at the lessons learnt, the tenets and even my black belt thesis with different eyes.
I've been thinking about the concept of [flow](http://en.wikipedia.org/wiki/Flow_(psychology) in programming and my general practice of computer science, graphics and art. When I trained in Taekwondo it took me at least 3 to 4 years before I had my first flow moment. I remember to this day, breaking two pieces of wood with a jumping reverse side kick. Its a cool move when done right and there was no effort or rather, no forcing of effort.
But what did that take? There is the idea of 10,000 hours of exercise in a subject before you master it. But that's not the whole truth. Each hour needs feedback and explanation. You need to know what you did right and wrong, to get feedback from yourself and from someone who knows more than you do. Every lesson would involve the walking-stance forefist punch and the L-Stance front kick. Every time, we'd have to punch harder and faster and improve or be corrected. It certainly helped.
Another friend of mine who programs a lot at CASA has spoken to me often about the movement away from real programming and towards the more mundane linking of various code snippets into a coherent whole. I think he's right. The bar has been raised whereby we can all produce a working product such as a web-service or iPhone app from other libraries, code from GitHub and similar. The real skill in programming isn't to do this, but only programmers can do this sort of thing well.
Recently, I worked on a piece of code that was written in Java. The time constraints were tight and the code was not legible or well constructed. I came in and was immediately stressed out. I did my best to figure out things but it took me an age to get the program to a state where it could work. In the end, it did (and you'll see the results on Sky1 sometime) but the originator of the code confessed he wasn't a programmer. But there we have it. Unless you practice the forefist-punch of programming, you can't make the good stuff.
Ok, this is probably well known in other disciplines but when you have been programming for a while and working for different clients and on different projects to tight deadlines, what exercise can one do that is similar to the forefist punch? Im not sure I know the answer. My previous little knightmare bash script might be seen as such a thing. Maybe its the python scraper I wrote to look for places to live in London? I suspect other programmers and creative types have their practices. The idea of the speedproject is one. Set a time limit and see how far you can get. Of course, the last thing you want to do is step back to something simple and non-job/non-client critical but I think your practice would improve.
I suspect I'll need to break out the C book again :)