For those who are unaware, one of my other hobbies is building historical harps and other musical instruments. In my studies of historical instrument building, I came across a luthier named Robert Lundberg. He passed away some years ago, but he was a skilled and brilliant researcher and luthier, and some things he said about skill building and mastery really rang true for me, and have influenced my view of success and skill advancement. I’m going to try to get some of those thoughts across here.
“Good Enough”
Robert Lundberg believed that a master’s quick and sure work in their craft was good enough, and they shouldn’t aim for belabored and technical perfection. He said:
“In my own work I have never pursued perfection, but rather I have pursued excellence, which I think is an attainable goal.”
In swordplay, for instance, it doesn’t matter to me *exactly* how to stand, as long as you understand what you are doing and why and that you are doing it in a structurally sound manner (e.g. you’re not going to do damage to your own body).
But what is a master?
In explaining what it means to be a master, Robert said this, which has profoundly affected the way I look at everything I do:
“There is a critical mass in any artistic endeavor, a critical number of instruments someone will build before they get beyond the nuts and bolts of it and do master quality work. These master works don’t begin all at once, but begin with one here and there, and slowly more and more until one constantly produces them.”
The way I view this in swordplay is that ideally, as you work toward this excellence, and you honestly reflect on your successes and failures and learn from them, you will eventually have a few fights here and there that seem to magically go the way you wanted. These will occur more and more over time, until you have gained enough understanding and skill that you can successfully manipulate a fight to your advantage no matter what’s thrown at you.
So what is success and what is failure?
An analogy of success and failure might be illustrated in the work of a programmer. Let’s say you are supposed to write an application for consistently winning sword fights. Imagine each skill or technique that you need to be proficient at is its own function or subroutine. So this application involves many subroutines working together, sometimes nested inside one another, sometimes working consecutively.
When you go to work on the application, you don’t usually expect to make the it work perfectly that first day, right? You want to work on a few subroutines and make sure they are doing what they are supposed to do, and that they work with other subroutines that you have already tweaked. Each day you work on it, you’re testing and tweaking those subroutines, trying to break them and see if they are responding predictably. (This is an important point - you are trying to push them to the point of failure, in many cases, in order to make sure they work)
Sword practice and even tourneys (which are themselves a form of practice) are the same way. If you focus only on being the winner of the fight, you may happen to succeed here and there, but your effort falls apart with new challenges that break your largely untested “subroutines.” But if you focus on making the individual subroutines run reliably with different input, eventually each one becomes solid and efficient against different inputs, and you begin to use them reliably together and see more and more success. Now this also means that in free-fighting practice, you will need to accept getting hit, or losing the exchange as you work through these things. Probably a lot. This is expected. You can’t improve your program until you’ve pressure tested it and found its weak points.
Back to the coding analogy - when you leave work at the end of the day frustrated that you couldn’t make the application respond predictably and you’re laser focusing only on the failure of the entire application, that’s going to be hard to fix. So instead you isolate some of the problems and you rework a few of your subroutines until they run properly, and you see where you next need to concentrate your efforts. You break the larger problem into its parts and improve them individually.
Eventually the application works well - not because you got better at writing applications, but because you improved each subroutine.
Similarly, if you go into a tourney fight, and you successfully manipulate your opponent into doing what you want, but you miss the timing at the end, then it’s only a failure if you don’t see the success and note where you need work. In my mind, no matter whether you win or lose, you should walk off that field with a tangible goal for improvement. And that is a success, to me. You can demonstrated that these certain subroutines work and you now have a plan to tweak even further.
Continually tweaking your subroutines until they consistently work well together under various test cases is the daily goal. NOT making the overall program work. The program working is the end result of a set of subroutines working well together. So the successes are getting each of those individual subroutines, or skills/techniques to work.
So in my view, a healthy way to go about learning a skill is to see and celebrate the successes in improving your subroutines.
Constant testing and tweaking is normal
A common occurrence is to get your program working well and then it suddenly fails with new/different input. Maybe you run into a fencer who fights in a way you haven’t encountered. So now you have to go back over your subroutines and make sure they work with this new input. Or you need to add a new one to your application. This is normal.
Focusing on the macro idea of just hitting your opponent may bring some success, but it’ll be inconsistent and ultimately frustrating. Whereas focusing on the building blocks of the fight will eventually lead to more success against more opponents.
You win multiple swordfights because you tweaked most or all of your subroutines and tried them under different pressure tests, and made sure they ran well together. Not because you focused on “winning a swordfight.”
And in my view, when all the subroutines are working well and can adjust to anything thrown at you and you just simply succeed, you’re becoming a master.
What do the historical manuals offer?
You can also look at the period manuals as a pathway through this analogy. A fencer can try to write a new subroutine for each new variation of a move or fight they come across, or they can work to make the subroutines they have more efficient and handle more variations – even variations they may not have encountered before - because they fall into a certain class.
I view most SCA and HEMA fighters as the former. They have built up their bag of tricks, and try to come up with new tricks as a way of adapting to new problems. But this can lead to way too many subroutines that cause unpredictable results. Or it’s an approach that creates fighters who are viewed as having one set of tricks that another fighter can take advantage of.
Whereas for me the period manuals usually are entry points to efficient systems that already been tested against many input and have been tweaked until they got to the core of the options and have, therefore, created a more efficient system with fewer subroutines. Getting to this point through my own trial and error would take way too long.
Granted - the period authors weren’t great for our modern eyes at explaining clearly the structures and the fundamental parts of their systems. So when studying swordplay it helps, I believe, to find someone who has reached that stage of mastery and who can help you understand how the subroutines in the period systems work with a variety of inputs.
Wrapping it up
Robert Lundberg described how he had built hundreds of instruments, and spent hundreds of hours in museums and libraries studying how the renaissance luthiers did their work and viewed their efforts, when one lute seemed to just fall out of his hands with little effort. Over time this happened more and more, until it became a relatively regular occurrence.
To him this meant that he had mastered many or all of the individual skills and choices that went into making a lute, and he was mostly unconsciously heading off problems before they appeared. His experience led him to account for the grain of a particular piece of wood, or for a bad batch of glue. He was automatically adapting to new inputs before they had a chance to throw off his work.
My own experience - in fencing and many other things - bears this out. When I started working on implementing the historical manuals, I eventually won a fight as if it were straight out of a manual. I set up my opponent and forced them to make the decisions I needed to implement the end goal of that play. It all came off smoothly.
Later - maybe weeks, maybe months, maybe more - it happened again. And then again. And after a while I found in roughly 1/2 my fights I could enter into an exchange, force my opponent into an action, and have the counter ready. And even in the fights that didn’t go as smoothly as I wanted, my subroutines often saved me before I got too deeply into trouble.
But leading up to those times that I won in the way I had planned, I also noticed when I got PART of the routine to work the way I wanted, but it didn’t go as planned, or I didn’t follow through as I should. Those were ALSO successes. And I hold that it’s vital that you learn to view them that way and even celebrate them - even when you weren’t the winner of that particular fight.
Conclusion
All thoughts are welcome on this, my musing of success and mastery. I imagine I will be tweaking this outlook the rest of my life. Maybe next I’ll go into some more depth about what I mean when I say “change your win conditions.” That’s a vital strategy to use with the above philosophy in order to find your successes and avoid burn out.
I really like the analogy to programming and how to judge success. The definition of mastery is really interesting too. I'll be stealing this programming analogy for some of my students who get stuck in the must hit the other person mode when they need more work tuning up the subsystems that support that endeavor. Thanks for this.