Summary
The more I practice taiji, the more I notice three seemingly contradictory things. First, I keep discovering subtle details that I hadn't previously seen. Second, it keeps getting simpler. Third, it never gets easier: our teacher, who has been doing it for twenty-five years, sweats just as much as the old fat guy who wears my outfit.

Advertisement

Subtle Detail

The other day I noticed, for the first time, that in "White Bird Spreads its Wings", Richard's right hand was extended much further off to his left side than I was doing, half-way through the move. I have watched him do this move a few hundred times and had never seen that before.

Getting Simpler

I tried for a while to add this to my version of the move. To make it feel even close to right seemed impossible, so I asked for help. He observed me, and told me two things: first, in the early part of the move, reach further straight forward, under my left elbow, palm up. Second, instead of twisting or reaching left to get my hand positioned as his is, don't worry about the hand. Take the next step, leading with right shoulder and hip. Leave the hand where it is and let the natural waist twist and step take the body into a position where the hand winds up where it belongs. The move wasn't about doing more to replicate his result: it was about doing less.

But Not Easier

Doing "White Bird" in this new way isn't easier now. I put just as much effort into the move now, and I always will. It goes more smoothly now, with less wasted effort, and with a better result. The more subtlety I'm aware of, the more simply I do the moves, the more my effort pays off. The final outcome is still the result of effort.

> <P>Could there be, just possibly, a parallel in software> development?</p>

I think there's a immediate parallel in software development, but only when you're trying to learn/do new things. Things that challenge you improve your understanding.

Whenever I see a master "hacker" explaining/discussing/coding/designing some ideas I always see them under a new light. After I understand this subtlety things look simpler, but my job doesn't get any easier, just more efficient.

Since I've started studying OO I thought I "groked" it 4 times. First when I learned about it, using Java. Then I studied safer languages (e.g. Eiffel, Sather) and got a new vision about what it was. Later I studied Smalltalk and Self, and started asking "Why classes?". Finally I read Cardelli and Abadi "A Theory of Objects", and Cardelli's Obliq and groked OO. Each time I saw a subtle detail (type parameters, message sends, prototypes, object literals) that wasn't there before (at least not explicitly). Each time it got simpler. But it still isn't easy to make these tiny objects work together ;)

* the posture and the sequences go sophisticated and complicated from the view point of other people, but it gets simpler from the view point of me. * the more I practice the motion gets natural, but the process is unnatural for me. * when the motion looks beautiful, I'm getting it right most of the time. * there is a kind of flow and rhythm sense in the motion -- the more I practice I can ride the flow and the rhythm. * symmetry, alternation, centers and etc. which Christopher Alexander metions in his recent book can be found in the form as well. The more I practice, the more beautiful the form is, and the more of those attributes I can find in the form. * there are some kind of generative rules. You learn a few simple rules and they generate a hundreds of rules. You simply follow a set of simple rules and there comes the emergence. You can say it got simpler because the number of rules reduced, but others will say it looks more complicated since they see more rules outside. If you try to follow those superficial rules it'll be really hard and you usually go the wrong path.

Observe by watching components, their direction, and rotation. The start and end point is important, but there is a line of movement in between that is more so. That's how you see that components aren't moving because they are already at the end point.

I agree that there's a lesson here about the subtle differences in otherwise identical movements between "masters" and "novices" and maintaining effort even as you improve. However, I see as well a lesson in the value of learning how to observe/learn and learning the best questions to ask.

What I think we really want is the ability to understand movement/design well enough that we can reproduce any particular movement/design in a form that is most appropiate to the current context. This is in contrast to just replicating/copy-and-pasting a movement/design.

i don't know what is more interesting: the waist/step guiding the hand, or the teacher/student dynamic. i'll comment on the latter because it looks like others have already commented on the former.

imagine, if you will, that software development were taught like tai chi. a master teaches some fundamental forms to his students. and they practice the same form or part of one form, over and over again. the master showing, watching, helping ...

the other day i noticed, for the first time, in our 554th time doing "complex number" implementations, that most of richard's if/thens were bunched up at the top of his methods. i've watched him do this implementation a hundred times and never noticed this before.

i started trying to add this to my version of the code. somehow the effect wasn't quite the same so i asked for help. he observed me and told me two things. one, we must try to express the main intent of a method clearly as possible. two, special cases tend to clutter the clarity of this expression. instead of pushing all your if/thens to the top of your methods. concentrate on clarity. the special cases will migrate appropriately.

perhaps after trying to decipher thousands of lines of my own code years after writing them, i might come to the same conclusion. but then again, maybe not. ...

but coding isn't taught like that. AFAIK, it's taught like math/physics. we can even get certified through some SAT-like testing. often i find the subtleties between the lines of good programming books. i imagine that most coding subtleties are passed on through code reviews or pair-programming.

perhaps, we need a "writing-and-rhetoric-type approach" where software development students go over the "classics" in open-source code. experienced coders assign the source code of entire modules/packages to their students, and go over the fine points in recitation.

then again, i suppose this vibrant developer community is perhaps an attempt to connect the wise to the wiser. maybe we arent so far off from the tai chi studio.

Could it be that we can learn a lot useful wisdom from other disciplines?Could it be that a good programmer ist a person with just a great general knowledge, paired with Rhetorics and understanding of Art?Maybe, it´s not too important if you take it from sports, music, literature, science or mythology?

However, I have the feeling that a programmer doesn´t get better, by programming only.