>Writing from Japan, we call this process "Shugyo" (austere training). A master carpenter spends years learning to sharpen tools, not because it's efficient, but to understand the nature of the steel.
Is there repetition implied? Would you build your own redis 20 times? (Just curious).
Great question.
If you simply copy-paste the code 20 times, that is meaningless.
"Shugyo" is about internalization.
The 1st time you build Redis, you learn the Syntax.
The 10th time, you understand the Structure.
By the 20th time, *the tool disappears.* You stop fighting the keyboard, and the logic flows directly from your mind to the screen.
In Kendo (Japanese fencing), we swing the bamboo sword thousands of times. Not to build muscle, but to remove the "lag" between thought and action.
Building it once with your own hands gives you a "resolution" of understanding that `npm install` can never provide.
I've always been fascinated by Japanese craftsmanship and aesthetic spirit. It's lovely in so many ways. At the same time, there's an opportunity cost to doing stuff like in "Jiro Dreams of Sushi" where you drill very simple things to absolute perfection, and I wonder under which circumstances this practice is the right approach versus those where it's sub-optimal given modern tradeoffs.
That is a sharp question. You are right about the opportunity cost.
As a banker, I look at the "Depreciation Period" (Lifespan) of the project.
If you are building a "Pop-up Store" (a prototype or script), use libraries. Don't waste time on craft.
But if you are building a "Shrine" (Core System/Database) that must last for 20 years, "Shugyo" is actually the cheapest option.
Efficiency is cheap now, but expensive later (Technical Debt).
Craftsmanship is expensive now, but cheap later (Stability).
We don't need a Jiro to run a fast-food franchise. But we need him to build the Kernel.
I enjoyed this explanation of how the philosophy of Shugyo-style training applies to software engineering. There are some choice phrases that describe the process of mastering an art.
> understand the nature of the steel .. the tool disappears .. to remove the "lag" between thought and action
Brilliantly said. Same with a musician practicing thousands of notes, scales, famous compositions - the repetition, accumulation of physical effort, trying things from all angles, thinking about it deeply, getting to know all the detail and nuance of sound, instrument, materials and conditions. As one trains there are breakthroughs in understanding and skill, building a kind of embodied knowledge and intuition beyond words.
I read your article. The rule of "Moving the stone only once" is profound.
It is the ultimate "Commitment," and it explains why Japanese walls survive earthquakes.
Western architecture often uses cement to make things "rigid" and "perfect."
But in Japan (an earthquake nation), rigid things snap and break.
Japanese stone walls (Ishigaki) have no cement. They are held together by balance and friction alone.
Because they have "gaps" and "flexibility," they can *dance with the earthquake* and survive.
We call this *"Asobi" (Play/Slack).*
Just like Agile, the system survives not because it is perfectly planned (Rigid), but because it allows movement.
Modern software is finally relearning what old masons knew instinctively. Great read.
Thanks, it’s a few years old. Rereading it now it’s kind of incoherent. But of primary importance now I think is the idea of making software (and systems) resilient, self healing. Traditional concepts of agile are mostly paved over with modern constructs and self-serving processes. I think AI will be an earthquake for many companies.
Shugyo will not be successful if you do not have Musha Shugyo attitude with necessary Heiho/Hyoho (Miyamoto Musashi/Yagyu Munenori definition) mindset ;-)
You speak the language of the blade.
Indeed, without Heiho (Strategy), repetition is just labor. With Heiho, it becomes refinement.
I bow to your insight.
Actually, I am drinking a Japanese Sake called "Jozen Mizuno Gotoshi" (The Highest Good is Like Water) right now to celebrate the New Year.
The name comes from Laozi.
Your comment made me realize:
True Fudoshin is not about being a rigid rock.
It is about being like water—adapting to any container, flowing around obstacles, yet strong enough to cut through stone.
Whatever happens in the market or in code, I want to be like water.
Happy New Year.
The idea is that you maintain a "Unshakeable Spirit/Heart/Mind" w.r.t. your ultimate goal (whatever that may be) but still keep your everyday working mind aware, adaptable, not losing heart when difficulties arise but working through them all with a sense of calm purposeful focused action.
The Fudōchi Shinmyōroku states that as, the "Right Mind" is like free-flowing Water (useful in any situation since it can quickly assess, adapt and respond) while "Confused Mind" is like congealed water i.e. Ice (not useful since it is static, fixed form and not adaptable).
In modern terms, we can restate it as goal setting, long-term strategy vs. short-term tactics, maintaining composure and fortitude while working towards the goal unceasingly.
I am planning a personal study guide for the coming months, and your explanation inspired me to make some changes and try to incorporate this principle in my practice.
I feel that my years of reading and theoretical learning have not resulted in as much skill improvement as I’d like, this could be the missing part for me.
I’m glad it helped. For years you’ve focused on the "Knowledge" (知). Now you are finally stepping into the "Action" (行).
In Japan, we call this unity "Chiko-Goitsu." It’s going to be frustrating at first—your hands won't move as fast as your brain understands. But trust me, that friction is where the real skill is born. Good luck with your study guide.
Not OP but I would and do write things 20x, for the simple reason that the 2nd is better than the 1st, even after refactoring the first, the 3rd better than the 2nd etc. We have a durable workflow thing from when it wasn't a thing yet (it was called enterprise workflow engine or something back then) which I started in PHP in the mid 90s, it has been rewritten by me over 30x and now its as optimal as it can be. It is finally finished. I have 20 year old clients who upgraded to it and are happier with the performance and stability. We do this with many parts of our software stack; not big refactoring but rewrite from scratch. One thing with this: in my opinion you can only rewrite if you are NOT adding any features; it should be a 1 to 1 rebuild.
30 times. And stable for 20 years.
You are the proof that "Slow is Smooth, Smooth is Fast."
I am just a loan officer observing the craft; you are the true Master Carpenter.
Respect.
yes, but it's not necessarily the same kind of repetitiveness in every industry.
In the tech space, Leetcode is repetitive by design, because after a while you realize the core problems are focusing on a half dozen different concepts. After getting good at throwing in a table, or whipping up a dynamic programming approach, you pull them out like you would a multiplication table that you memorized back in elementary and build from there.
There's questions on if this is a valuable skill in practice, where you'll be thrown into the weeds of many unfamiliar problems constantly. But it sure will make you look competent when at the interview stage. And maybe feel confident as a craftsman when you don't need to refer to documentation every 5 minutes.
Mike Acton talks about deliberate practice in programming exactly this way. Every day start with a blank sheet and try to build something for an hour (his example is Astroids). Next day, start again and get a little further. Eventually you'll be able to build the whole thing in an hour.
I am not a programmer, so I did not know the name.
But I just looked him up, and I can see why he is a legend.
His philosophy—stripping away the unnecessary to focus on the reality (data/hardware)—resonates deeply with me.
The practice you described (building from scratch daily) is exactly the "Tea Ceremony" of the digital age.
It is not about the tea (the result), but about the procedure (the internalization).
Is there repetition implied? Would you build your own redis 20 times? (Just curious).