The other night, I decided it was time to work on tsuki kotegaeshi again. This is not an uncommon thought that runs through my head when I’m teaching. In Kokikai Aikido, we have four techniques that are part of the first test a student might take: kata-tori ikkyo, katate-tori shihonage, ushiro kubishime kokyunage, and tsuki kotegaeshi. (If you know these terms, great. If not, don’t worry about it. It’s not really that important here.)
Tsuki kotegaeshi is an interesting technique. For the uninitiated, the technique is a defense against a straight punch. The response leads to a joint lock that involves the attacker’s wrist turned in a way not normally recommended. It’s an old technique, harking back to the day when someone was likely to charge you on the field of battle. Today, it is less relevant from a self-defense perspective, primarily because people aren’t normally on the battlefield—they’re in a bar, or a schoolyard. The punch is different.
So why learn the technique? The answer is simple. There is so much going on in tsuki kotegaeshi: how to enter, how to turn, how to use your hips to take balance, how to control, how to apply power, how to show restraint. This one technique packs more content than a dozen other, more “practical” techniques.
But we can take this further. Even in a fundamental technique like tsuki kotegaeshi, there are layers of functionality. For example, a lot of students get distracted by the kotegaeshi response. They are so focused on the jointlock, that they lose sight of a more basic principle: the importance of taking your attacker off-balance. To highlight this, I demonstrated the technique using only two fingers (one from each hand). This is NOT practical in any way, shape, or form; that wasn’t my intention. My intention was to show the technique in the most minimalistic way possible, while retaining the essence of the movement.
The following day, while at work, I was trying to think of how to best write some sample code for an API that I am documenting. Writing sample code can be tricky. You want the sample to fully represent the capability of the API; at the same time, you don’t want to actually write a full-fledged application (that’s the job of the developer reading the docs). In other words, the challenge with writing sample code is rarely where to start, but more when to stop.
As I was planning my work, the previous night’s aikido class came to mind. What I essentially needed was to do kotegaeshi with two fingers, but with code. I needed enough code so that a developer would understand the essence of the feature, but avoid anything that would prove too distracting. The goal of sample code is not to demonstrate the feature per se, but to demonstrate the essence of the task that the feature accomplishes. Of course, the sample code is going to include the feature, method, or property; but it is a waypoint towards a larger goal. The sample doesn’t even have to be practical in a “drop-this-in-and-away-you-go” sort of way. It needs to give the developer just enough that they can apply the feature in a way that best suits their needs.
To paraphrase a well-known expression: a perfect sample code is not when you have no additional code to add, but when there is no remaining code to take away.