6 ms·

>Writing from Japan, we call this process "Shugyo" (austere training). A master carpenter spends years learning to sharpen tools, not because it's efficient, bu

>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).

jebarker 10mo ago
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.
- 578_Observer 10mo ago
  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). Thank you for introducing me to such a Master.
anonzzzies 10mo ago
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.
- 578_Observer 10mo ago
  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.
578_Observer 10mo ago
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.
- CuriouslyC 10mo ago
  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.
  - 578_Observer 10mo ago
    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.
  - dripdry45 10mo ago
    Define "optimal" once you’ve done this 10,000 times perhaps you will find your answer.
- pcmaffey 10mo ago
  I’m legit curious what you think about (Origins of Agile in Japanese Stone Masonry) [https://pcmaffey.com/origins-of-agile/ https://pcmaffey.com/origins-of-agile/]
johnnyanmac 10mo ago
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.

jebarker 10mo ago

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.

578_Observer 10mo ago
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). Thank you for introducing me to such a Master.

anonzzzies 10mo ago

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.

578_Observer 10mo ago
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.

578_Observer 10mo ago

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.

CuriouslyC 10mo ago
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.
- 578_Observer 10mo ago
  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.
- dripdry45 10mo ago
  Define "optimal" once you’ve done this 10,000 times perhaps you will find your answer.
pcmaffey 10mo ago
I’m legit curious what you think about (Origins of Agile in Japanese Stone Masonry) [https://pcmaffey.com/origins-of-agile/ https://pcmaffey.com/origins-of-agile/]

johnnyanmac 10mo ago

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.