Shuhari, as a concept, is rooted in traditional Japanese martial arts with a philosophy focused on learning and mastery. This seems fitting considering Ruby is a programming language created by Yukihiro “Matz” Matsumoto who is Japanese along with some of the Ruby core team members. Neither are intertwined but Shuhari, as a concept, and the Ruby language, both being Japanese, is interesting because the journey to mastery takes years of grit, rigor, and continuous practice.
The word, "Shuhari", is composed of three Japanese characters:
-
Shu (守): Means "to protect" or "to obey". This represents the initial stage of learning, where the apprentice closely follows the teachings and techniques of the master crafter.
-
Ha (破): Means "to break" or "to diverge". This represents the intermediate stage, where the apprentice becomes a journeyer and starts to experiment, modify, and even break away from established rules and patterns.
-
Ri (離): Means "to leave" or "to detach". This represents the advanced stage, where the journeyer has fully internalized the fundamentals and can freely improvise, transcend the limitations of the original teachings, and develop their own unique approach.
Shuhari is believed to have originated in the early 17th century, during the Edo period in Japan, as a way to describe the progression of learning in traditional Japanese martial arts, such as Kendo, Judo, and Aikido. Fast forward to the early 2000s — where Martin Fowler equates this to imitate, assimilate, and innovate — and you find Shuhari used in software engineering to describe the progression from learning best practices and following established methodologies (Shu), to experimenting and adapting them (Ha), to developing one’s own innovative approaches (Ri).
I’ve also heard Shurari compared to agile but don’t feel that’s the right analogy due to the length of time required to acquire mastery. I tend to like the following break down which stems from Developer Hegemony by Erik Dietrich as based on medieval guild terminology:
-
Shu (Apprentice): Learn from the best through imitation, mimicry, and tons of practice until the concepts sink in so you can clearly articulate what you’ve learned with confidence.
-
Ha (Journeyer): Begin to diverge from your original teachings through experimentation, breaking down and rebuilding what you know, and finding your own voice, style, and signature to writing and solving problems.
-
Ri (Crafter): Evolve to complete mastery to where you can quickly move within the language with low friction, pull from a reservoir of hard won tacit knowledge, freely apply patterns (and deviate from them when appropriate), know how to debug issues quickly, think deeply about the entire architecture in terms of consistency and reduced duplication, and can teach all of this by mentoring and growing new apprentices.
This mirrors nature by starting out as a seedling (apprentice), growing into a sapling (journeyer), and becoming a mature tree (crafter). Definitely an oversimplification of stages of growth but is a nice visualization none-the-less.
The point of all this — no matter which mental map you choose — is Shuhari is great for distilling the process of knowing nothing to eventually becoming a master of the craft. For me, this is pure joy because there is no limit in what you can do and the possibilities are endless in what you can achieve…but the path is not easy, takes time — years, in fact — and few make it all the way. So let’s focus on why this is rare in software engineering with some personal experience sprinkled in for levity.
Shu
Back in the late 1990’s, when I first entered the software industry (and fresh out of college), I got lucky to be under the tutelage of a master of the Smalltalk language who later helped me hone my Java skills. Instant access to information in terms of articles, screencasts, podcasts, tutorials, and more wasn’t as prominent. Especially when only equipped with a 56K dial-up modem (well, initially, that is). Having someone to help level up my skills was priceless. I’m not only talking about learning the language but also the patterns, theory, and entire tool chain that goes along with whatever language you are writing in. For example: project management, team coordination, shell scripting, version control, deployment automation, databases, etc.
None of this was easy, either. I remember thinking no matter how hard I pushed myself, my sensei — so to speak — would barely acknowledge my accomplishments and then break my mind by revealing new or better ways in which to accomplish what I thought was terrific but still paled in comparison to someone who was a master of the craft.
I was a humble apprentice (well, sort of 😅) but definitely drank from the firehose to take in all I could even if I didn’t fully understand. This mirrors what "Shu" is all about: "where the apprentice closely follows the teachings and techniques of the experienced crafter." I had lot’s of information but needed time to convert all of this into experience and wisdom. There is no fast tracking any of this. I wish there was but nothing worth achieving comes easy.
I share this story because this experience is rare, especially today, where you don’t have an opportunity to hone your craft while on that job especially when you need to live with your mistakes and see how those early decisions either help or hurt you years later. Spending years developing and maintaining open source projects is one way to think deeply within a problem space but not everyone has time to spend evenings and/or weekends on dedicated work like this.
Having the time to be an apprentice (Shu) so you can become strong enough to gain independence as a journeyer (Ha) is not only good for the those new to the industry but buoy’s the entire industry as a whole. This makes our profession stronger, not weaker, and is is why spending time collaborating with someone who knows more than you — or time devoted to your own practice — is necessary to reach the next stage.
Ha
After spending years as an apprentice, I eventually transitioned into Ruby and fell in love with the language versus Java which required two to three times more syntax with a ridiculous amount of braces. Bah! Also, the way my mind is wired translated well into Ruby code than any other language. This is still true today. Although, Elm is a close second.
I was an apprentice evolving into a journeyer by entering the "Ha" stage despite picking up a new language. I was staring to experiment, modify, and break away from what I knew while, at the same time, applying what I did know to Ruby. I made a lot of mistakes, as any journeyer, but this time I was on my own learning the idioms of Ruby and rethinking what I knew. This is always a major stage of growth when you gain enough independence to think, rethink, and stretch your comfort zone.
It’s important to emphasize that the "Ha" stage takes longer that most people realize and the software industry is especially bad at dolling out inflated titles to folks with only a couple years of experience. To add to this, Ruby is deceptively simple to pick up but takes years to master. To be clear, I’m not throwing shade on Ruby. The fact that Ruby is a language that is quick to grasp is a testament to the design of the language but Ruby treats you with respect by assuming you’ll:
-
Write code that is easy to read and maintain.
-
Write well tested code that is easy to refactor.
-
Avoid monkey patches (just because you can doesn’t mean you should).
-
Default to simple solutions instead using metaprogramming as a solution to solve every complication (once again, just because the language makes this easy, doesn’t mean you should).
-
Maintain consistent style even though there are multiple ways to solve the same problem.
You could say the above applies to most languages but with Ruby being a dynamic language — with free reign to modify nearly every object — you are given a wide berth in which you can contort the language that can take what is normally pure joy to work with into a hellish nightmare.
This is a critical juncture where, at the end of the "Ha" stage, you hit a fork in the road. If you take the red pill, you’ll gain mastery by entering into the "Ri" stage. If you take the blue pill — and to reference Eric Dietrich once again — you’ll end up as an Expert Beginner by never reaching your full potential while having entered a false sense of proficiency which not only harms you but your team and poisons the industry as a whole.
Ri
Reaching "Ri" — and to re-quote from the above — means you have "fully internalized the fundamentals and can freely improvise, transcend the limitations of the original teachings, and develop their own unique approach." There’s more to this, though:
-
Never rest on your laurels. Most of us get into the industry because we enjoy the change and endless hunger to learn new and more efficient ways of solving problems but, at the same time, this doesn’t mean you can ignore the lessons of the past through good Git Commits, applying Second Order Thinking, building upon well established — even boring — standards like SQL, HTTP, REST, HTML, CSS, etc. instead of always chasing the new and shinny.
-
Always be evolving your skillset. Relearn what you thought you already mastered. An analogy is when Neal Peart (🪦) of Rush relearned how to play the drums under the tutelage of jazz drummer Freddie Gruber. At the time, Peart was already an excellent and well established drummer but he took the time to grow his skills even further. I realize Rush is an acquired taste for some folks but, regardless of your musical interests, is an impressive feat none-the-less.
-
Maintain constant rigor. There is no silver bullet. Constant practice, endless learning, intense rigor, and a never ending drive to continuously improve is the answer.
-
Be kind. This is probably the rarest of all skills in the industry because, yes, you need technical chops but the soft skills in terms of reading the room, being empathetic, treating others with respect and dignity is even more rare.
-
Never assume you’ve reached mastery. Stay humble, curious, and always be learning. Once you break the ceiling of what’s possible, set a new goal and break that!
At a minimum, ten years is where you enter "Ri" and even that is probably being generous because it’s not only mastery of the Ruby language but also mastering your entire tech stack (think: full stack). Example: Git, Bash, CSS, HTML, HTTP, SQL, Terraform, Docker, and more.
I’ve been writing Ruby for a couple decades and I still find new ways to challenge my thinking, fold into my practice, and evolve the craft further. Am I master? Have I reached "Ri"? Yes and no. Sometimes I think so and other times I’m proven wrong. Thankfully, solving hard problems is generally faster than when I was in the "Shu" and "Ha" stages. Also, you recognize common patterns for solving problems quicker. This includes leaning on a large toolset, built up over years, to provide elegant solutions to common problems.
Conclusion
A relevant documentary is Jiro Dreams of Sushi (including the clever, and complimentary, use of Philip Glass' music) where you walk in the shoes of Jiro Ono as an 85 year old master of the craft (sushi). Watching a kindred spirit practice the craft day in and day out while fully understanding the joy that brings not only to yourself but others who are willing to listen and learn is Shuhari incarnate. When done well, this translates into delivering a quality product that not only enhances your customer’s lives but brings them joy (even if they don’t fully understand what makes the experience magical).
Shuhari is worth the effort — and sometimes pain — because it’s a better life to live especially if you’ve only got one chance to do this well. If you need more encouragement, here’s a few a quotes which bolster the concept of Shuhari further:
Fall in love with some activity, and do it! Nobody ever figures out what life is all about, and it doesn’t matter. Explore the world. Nearly everything is really interesting if you go into it deeply enough. Work as hard and as much as you want to on the things you like to do the best. Don’t think about what you want to be, but what you want to do.
I see a lot of people with talent but the one thing they don’t have is that just love of doing it for the sake of it.
You don’t need more intensity, you need more consistency. Intensity impresses; consistency transforms.
If you really want to be great at something, you have to truly care about it. If you want to be great in a particular area, you have to obsess over it. A lot of people say they want to be great, but they’re not willing to make the sacrifices necessary to achieve greatness. They have other concerns, and they spread themselves out. … Greatness isn’t easy to achieve. It requires a lot of time, a lot of sacrifices. It requires a lot of tough choices. It requires your loved ones to sacrifice, too. So you have to have an understanding circle of family and friends. People don’t always understand just how much effort from how many people goes into one person chasing a dream to be great. There’s a fine balance between obsessing about your craft and being there for your family. It’s akin to walking a tightrope. Your legs are shaky, and you’re trying to find your center. Whenever you lean too far in one direction, you correct your course and end up over leaning in the other direction. So you correct by leaning the other way again. That’s the dance. You can’t achieve greatness by walking a straight line.
98% of success is consistently doing boring things that no one sees. 2% is visible and exciting, so that’s all everyone talks about.