Software development and martial arts August 30, 2025
I began my martial arts training when I was in school, at about the same time as I got my first computer, my father's old Schneider Euro PC. It came with GW BASIC, which got me into programming. Both activities have been part of my life since then. In martial arts, I started off training Goshin Jitsu, a little-know style similar to Jujutsu, then added Judo and Shotokan Karate before settling on Aikido. In programming, I progressed to QBasic, dabbled a bit in assembler, then got into C and C++ and tried countless other programming languages. After school, I studied computer science and began my career as a professional software developer.
So I've been practicing both martial arts and software development for about 30 years now, and I think I can say I have made a fair amount of progress since then – in both areas. Over the years, I have come to notice a kind of synchronicity of progress in my martial arts and software development skills. There were periods where progress stalled and I was frustrated because I felt that I was stuck. There were periods where I was preparing for a martial arts examination at the same time as I was preparing for a salary negotiation. And the major successes (taking over a martial arts class, leading a development team) came remarkably close in time, too.
On the one hand, this came unexpected because on the surface, typing code seems to be very different from throwing people to the ground. On the other hand, there obviously is a common element – me – and my personal development showing in both areas is not that surprising. Or is it? Why should progress I make in my martial arts training affect how I approach software development and vice versa? This only makes sense if there are other commonalities which make experience gained in one area somewhat transferable to the other one.
Thoughts about these commonalities have been bouncing around in my head for quite a while now, and, beginning with this blog post, I am going to write them down (in no particular order). I don't know how this is going to turn out – if my ramblings will be comprehensible to anyone other than me – but hey, it's my blog, and I can post whatever I want, so here you go.
I'll start off with the observation that developing software is not only about typing code; and martial arts is not only about throwing people to the ground, either. These are just the externally observable behaviours of software developers and martial artists, respectively. In reality, both software development and martial arts are about dealing with people. We develop software for people. To do this successfully, we need to understand their needs, not just the stated requirements. Talking to customers is as much part of software development as writing code is.
The preface to the classic computer science text Structure and Interpretation of Computer Programs says that
“programs must be written for people to read, and only incidentally for machines to execute.”
Again, this highlights the importance of people to the software development effort – this time, the developers themselves. You cannot successfully develop software by only thinking about the program text and the machines that will execute it. Future developers (including your future self) are the main audience of the code, and you need to anticipate how they are going to interpret (and change) what you wrote.[1] As you get deeper into software development, you realize that dealing with the machines is actually the easy part. The much harder and, for better or worse, much more high-leverage part is dealing with the humans involved: customers, other developers, other roles in the organization.[2]
Likewise, martial arts (in the sense of Budō) are about dealing with people, and by “dealing”, I don't mean the purely mechanical exercise of deflecting a blow by an opponent or applying leverage to down someone twice your weight. Ideally, martial arts are about ending conflict. As Ueshiba Morihei, the founder of Aikido, tells us in The Art Of Peace,
“The real Art of Peace is not to sacrifice a single one of your warriors to defeat an enemy. Vanquish your foes by always keeping yourself in a safe and unassailable position; then no one will suffer any losses. The Way of a Warrior, the Art of Politics, is to stop trouble before it starts. It consists in defeating your adversaries spiritually by making them realize the folly of their actions. The Way of a Warrior is to establish harmony.”
This requires seeing beyond the blow to the person dealing it, their motivation, emotional state, and capabilities. Merely deflecting a blow rarely solves a problem, and throwing your opponent to the ground only replaces one problem with another. (What will you do next?) Properly ending conflict is not achieved by fighting against an enemy (although ensuring survival is certainly necessary) but rather by engaging with the other party. Just as developing software benefits from engaging with your stakeholders rather than decoupling from them as far as possible.
As a boy, I've always been very good at the “hard” skills (logic, hitting an opponent, concise writing, hard/blocking techniques, …) and, I am afraid to say, bad at the “soft” skills (empathy, connecting with an opponent, active listening, soft/flowing techniques, …). I learned about the importance of connecting with people slowly over time. As I practised accepting attacks more softly, I came to realize that the same softness helps when accepting code reviews. When I learned about the “Yes, and” rule in a business context, I linked this mentally to the martial arts principle of using the attacker's energy instead of stopping it, strengthening the idea in my mind for use in both contexts. Synchronicity.
To be continued.
Footnotes
Incidentally, this is why I prefer to talk about “developing” software rather than “writing” software or programs. In the context of programming, “writing” is often confused with “typing”, even though pretty much nobody would equate those two words when talking about the production of other texts like a novel. ↩︎
I could go on, mentioning Peter Naur's Programming as Theory Building, Conway's Law, the difficulty of making, communicating and enforcing architecture decisions, etc., but suffice it to say, software development is a people business. ↩︎