"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.
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... .