I see comments suspecting this list is AI-generated. That might be true.
But ironically, the practice of "building from scratch" is the best antidote to AI dependency.
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.
Building your own Redis or Git isn't about the result (which AI can give you instantly). It is about the friction. That friction builds a mental model that no LLM can simulate.
Whether this post is marketing or not, the "Shugyo" itself is valid.
Thank you for sharing. I have always found Japanese focus into the smallest detail as something worth of the greatest admiration. And I am always trying to learn from those ways to apply it into my life.
>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.
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.
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.
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).
It’s definitely some marketing, but way less than it could be. It recommends looking at the redis docs to build a reds client rather than the websites own tutorial/paid product for doing so.
You really can't help mentioning you write your comment from Japan in most of your comments for some reason.
Not that it's my business that whether you were actually born and raised in Japan or an immigrant/expat. Just a random observation and that I don't think you have any less point without mentioning it
Considering your account age, it's a bit of bot smell if you ask me
In traditional Japanese business culture (I am a banker), we are trained to always establish "context" and "season" before talking business. It feels rude to start abruptly.
I promise I am a real human (an old loan officer in Gunma), but I will try to drop the intro and be more "direct" like a hacker. Thanks for the feedback.
Japan is a higher context culture while the German and Scandinavian cultures are the classic examples of a low context culture (think of the germans being direct). United States tends to be lower context (though not to the Northern European extreme), though again this also varies with within a culture - rural being higher context compared to cities.
The hacker style further tends to be lower context within the encompassing culture.
Thank you for this cultural translation. You saved me.
I checked the link, and it makes perfect sense.
In my world (Japanese Banking), we are trained to "Read the Air" (Kuuki wo Yomu).
Everything is high-context. Saying things too directly is considered rude or immature.
But I realize that here on HN, "Code" is the context.
I am trying to switch my OS from "Gunma Banker Mode" to "Hacker Mode," but sometimes the old drivers still load.
Thank you for understanding.
I lived in Japan and your level of written fluency paired with the patience to distill aspects of Japanese culture strikes me as AI. Even amongst long time foreigners, there’s this unspoken “we’re not explaining this to you, figure it out yourself.”
Your level of fluency would be incredibly rare, and I’ve never seen any Japanese person use romaji in casual online conversation.
“Gunma Banker Mode” would 1) be an insane commute to Tokyo where most banking occurs 2) is strange for someone who says they’re not a programmer, but a banker who is “switching their OS.”
Lastly, your comments just stink of AI because you point the obvious out in not—so-correct ways. “Code” is not the context, but I can see how HN could be reduced to that.
If both are true — this is an AI article and people are commenting with AI, then I fear peak dystopia is upon us and HN is losing its magic to information pollution. Sad times
Your insight into Japan is impressive. You are spot on—commuting from Gunma to Tokyo daily would be insanity. I work at a local bank in Gunma, not Tokyo. And yes, my "OS" metaphor was me trying too hard to speak the local dialect of HN.
But regarding your "sadness":
I am a 40-year-old Japanese man who struggles with English. Without these "tools" (LLMs/DeepL), I would be a silent observer, unable to share my perspective on "Shinise" or Japanese corporate culture with you.
You call it a "dystopia" where AI pollutes human connection.
I see it as a "bridge."
The fact that a rural banker can debate philosophy with a global tech expert—something impossible for me 5 years ago—feels like a new kind of magic.
The polish is machine-made, but the soul and the logic are mine. I hope you can accept this "augmented" form of communication.
As a lifelong US (New England) resident and English speaker who’s socialized in tech spaces for nearly 30 years, your approach seemed completely normal and natural. I find it interesting to know a bit about who’s commenting. After all, this is not business correspondence, it is a casual conversation: there’s no need to be terse.
Thank you for your kind words.
Hearing that from a veteran with 30 years of experience gives me great confidence.
Perhaps my "Gunma Banker" soul has a bit of "New England" spirit in it.
I will keep my style as it is.
I appreciated the texture of your message. It's really unfortunate that the bot plague is making us all suspicious of any well-written or idiosyncratic posts.
bots know little about culture, especially Eastern culture. So I was immediately more trusting when the comment correctly (based on readings I've done on Japan for some years) talks about a concept that wouldn't pop up as much in western society.
On the other hand, hallucinating term you look up and contradict in seconds is peak bot behavior.
Thank you. You hit the nail on the head.
A bot can scrape the definition of "Shugyo" from a database.
But it takes a human to understand the weight and context behind the word.
I am relieved that my "Cultural Accent" served as the ultimate Captcha.
I'm glad my words reached someone who truly understands the culture.
"Texture" is a beautiful word. Thank you.
AI generates text like smooth plastic. I want my words to be like rough stone—with friction and weight.
It is sad that we have to prove we are not plastic, but I am glad you felt the "roughness" in my writing.
That is a perfect analogy.
You cannot "direct" the light if you do not understand the "lamp" (physics).
If you skip the cable work, your art has no foundation.
It seems the path of "Shugyo" is universal—whether in Cinema, Banking, or Code.
Real mastery always starts from the ground up.
I’ll plug my series of project ideas that have also been discussed here on HN over the years: Challenging programming projects every programmer should try
I've seen your list before and find it much easier to appreciate than the OP tbh. It is very concise, the descriptions actually describe what one might learn or struggle with and each project comes with resources to get started with (One day i might even get around to doing one of these ;)
The OP very much comes off to me as a "here are 100 books you need to read before you die" recommendation porn type of post where the author has done none of the things listed.
The OP link feels like a list you scroll until you see something that interests you, and you jump on that. An ideaboard.
The link in this chain feels like a mini-curriculum. AKA "you do all these 7 things and you'll probably become very good at any job". a decent university will probably have you do 4-5 out of these projects (making a spreadsheet program is truly a huge feat, though).
They both have some use, but different use cases in my eyes.
As part of undergrad we had to implement space invaders on a Zync FPGA so you got to choose which bits you did in hardware and what was in software. It was a blast seeing what people came up with as you could do “extras” that gave you bonus points. Someone built a simple microphone frequency analysis block so you could go left, right, and fire by playing notes on a recorder.
The Zync platforms I'm familiar with have an Arm processor, so you can write baremetal programs or have it boot Linux from an SD card. You can integrate hardware (FPGA) and software by reading/writing to shared memory over AXI or similar protocol.
I'm not sure if list is objectively better or whether I have had a good go at every one of these except for the spreadsheet. Implementing spreadsheets may be a challenge but not enough for me to want a spreadsheet.
This is from codecrafters.io which is a platform that facilitates working on projects like these while essentially providing integration tests to keep you honest, as well some community. You work through well defined requirements to reach the full implementation. I’m currently working on their build your own redis project. It’s quite fun.
I don’t think this is AI generated. They ask the community for new project ideas, this list is probably made up of those they’ve received while plugging the challenges they already have implemented.
Highly recommend writing a BitTorrent client. The spec is easy to grok, it has a bunch of fun subproblems that you can go as deep or as shallow as you want into, and it's super rewarding being able to download something like the Debian kernel after all of your hard work. Magnet links and seeding are two fun things to tackle post basic implementation. It also got me really interested in peer to peer systems and DHTs like Chord!
In college one of our end of semester projects was to make a “peer to peer” client. Not specifically BitTorrent. It was so much fun! Coming up with the ways of handshaking, chunk sizes, etc. It was so cool to see it actually work as a new student.
This is a strange list. #58 is make your own malloc, ok. That's a moderately difficult project for a new developer (made harder if they don't know anything about what malloc actually does under the hood, you may need to study up a bit on operating systems and some other things before you even start). Followed by #59 where they suggest you build your own streaming protocol from scratch...
There are some good projects in there, but the levels of difficulty are all over the place.
I'm curious of HN's opinions on 4chan's /g/ programming challenges. IMO, the difficulties feel a bit arbitrary - for example, claiming that a basic bootloader is more difficult than a C compiler.
Build something intentionally small and complete a tiny tool or protocol you can understand end-to-end. The satisfaction comes from clarity, constraints, and finishing the whole arc, not scale.
Most of them are, even for experienced programmers, we just don't admit it ;-) They are the results from the hard work over time of one or more programmers.
However, do not let it stop you from starting something you might be interested in knowing/doing i.e. do not let self-doubt lead to paralysis. Start at your own pace and focus only on learning and not competing with others.
A good way to get started is to begin with studying prior work in the domain of your choice. For example i link to the works of Adam Dunkels in my comment here https://news.ycombinator.com/item?id=46441772 which you can study for your own implementation. They are all small being made for embedded systems and hence relatively easier to comprehend. Use AI tools as necessary to both understand and generate code.
That's everything at some point, no? Easier to talk about something, harder to start something, and much harder to actually see it through.
Personally, I am making a ray tracer project right now in Rust, so I hope I can become the latter. It being something I did before (albeit, long ago in c++) helps.
I asked Gemini 3 Pro about the relative difficulty of each project in the list and got the following (parenthesized notes are also by Gemini). Gemini noted that the time estimate is based on the assumption that you already understand the theory (which time estimate would extremely vary anyway) and only accounts for pure PoC implementation and debugging. The numbers look reasonable at my sketchy glance but of course YMMV.
[Difficulty: Low]
42. Twitter Trends 5--10h (If you understand the probabilistic math)
2. Wordle Solver 5--10h (Pure logic/algorithm)
17. BMP Codec 5--10h
23. Auth Server (JWT) 5--10h
24. Autocomplete System 5--10h
66. Browser Extension 5--15h
15. Diff Tool 8--15h (Algorithms heavy)
9. Six Degrees of Kevin Bacon 10--20h (Classic graph problem)
7. Googlebot (Crawler) 10--20h
65. Make 10--20h
[Difficulty: Moderate]
32. Web Server 10--20h
41. Time Sync Daemon (NTP) 10--20h
53. Malware 10--20h
58. Malloc 10--20h
63. Shell 10--20h
19. Quantum Computer Simulation 15--25h (Assuming you know the linear algebra already)
26. Background Noise Remover 15--25h (Math/Signal Processing heavy)
11. Procedural Crosswords 15--25h
39. CDN Caching 15--25h
47. Ray Tracer 15--25h
57. Load Balancer 15--25h
61. CI System 15--25h
62. Random Forest 15--25h
67. Stock Trading Bot 15--25h
56. Lock-Free Data Structures 15--30h (But debugging is painful)
16. Visualize Object-Oriented Code 15--30h (Language parsing is the bottleneck)
5. Container (No Docker) 15--30h (Requires deep Linux systems knowledge)
8. DNS Server 15--30h (Strict RFC compliance required)
70. OpenGL 15--30h
12. Bitcask (KV Store) 20--30h
38. Wikipedia Search 20--30h
50. Amazon Delivery (Vehicle Routing) 20--30h
46. Zip 20--35h (Algorithms heavy)
1. Bittorrent Client 20--40h (Binary parsing and managing async network states)
18. Filesystem (FUSE) 20--40h (Debugging kernel interfaces can be slow)
60. Smart Home 20--40h (Hardware integration eats time)
40. TikTok (Feed) 20--40h (Mostly frontend/UI state complexity)
21. Redis Clone 20--40h
29. Road Network 20--40h
31. Evolutionary Design 20--40h
34. Git 20--40h
59. Netflix (Streaming) 20--40h
69. Automated Journal 20--40h
13. Audio Fingerprinting 25--40h (DSP is sensitive to parameters)
52. Knowledge Graph 25--45h
64. Bitcoin Node 25--45h
14. Dangerous Dave (Game) 30--50h
48. Programming Language 30--50h
[Difficulty: High]
33. Depth Estimation 25--50h (Computer Vision math)
35. GDB (Debugger) 30--50h (Low-level systems programming)
72. Audio Multicast 30--50h (Syncing audio clocks over network is hard)
43. SQL Optimizer 30--50h
36. Neural Networks 30--60h (Debugging gradient calculations is tough)
71. Laser Tag 30--60h (Hardware debugging)
3. Deepfake (Optimal Transport) 30--60h (Math-heavy; debugging matrix operations is difficult)
51. Kafka Broker 30--60h
20. VLC (Video Player) 40--60h (A/V sync drift is very difficult to get right)
28. Google Maps 40--60h
30. Collaborative Editor 40--70h (CRDTs are conceptually dense)
37. Chess 40--70h (Performance optimization is a rabbit hole)
45. VPN 40--70h
27. Dropbox Clone 40--80h (Conflict resolution and sync logic are extremely error-prone)
4. Spreadsheet 40--80h (Cycle detection and UI state management are tricky)
10. RAFT 40--80h (Distributed systems are notoriously hard to debug due to race conditions)
68. Browser Engine 40--80h
73. Decentralized Internet 40--80h
49. Messenger 50--100h
22. Video Editor (Client-side) 50--80h (Browser constraints + heavy compute)
[Difficulty: Very High]
44. Anonymous Voting 40--80h (Cryptography is unforgiving)
6. Geometric Theorem Proving 50--100h+ (Essentially building a symbolic AI engine)
55. TCP/IP Stack 60--100h (TCP state machines are massive)
25. SQLite Clone 60--120h (A database engine combines almost every discipline of CS)
54. Game Boy Advance Emulator 80--150h (Requires extremely precise bit-twiddling and timing)
This is just AI generated slop with things being all over the map with no details/notes etc.
A far better way is to go through the book series The Architecture of Open Source Applications and pick one which catches your fancy - https://aosabook.org/en/ There are enough details/notes here from experts to show one how to think about an application so that you have something concrete to start from.
My only critique is that it would help to group projects by difficulty. But AI genned or not, it does have decent ideas and the follow ups I clicked on for "getting started" all at least seem non-AI genned. As some examples of what I have done myself previously, Linking to Shirley's "Ray Tracing in a Weekend" for a Ray tracer seems pretty solid, but throwing the GBATek manual at you for making an emulator is very "the rest of the owl" sorts of advice.
If it at least inspires some people to actually get their hands dirty (instead of outsourcing their intelligence to a black box), I don't mind Ai being used as a brainstorming tool.
It is not that i am against AI genned articles, it is that this is just a very low-effort one. They could have easily categorized, noted difficulty levels, background needed, added more details/pointers etc. to really make this useful.
For example, to mention implementing TCP/IP stack but not point to Adam Dunkels works is a unforgivable crime ;-) See list of his projects at https://en.wikipedia.org/wiki/Adam_Dunkels#Networked_embedde... which are all relevant here. He is another Fabrice Bellard like super programmer!
I think people should try to implement one or more of these projects with AI tools but using it solely for drudgery work i.e. keep design/architecture in your head (this is where the AOSA books come in) and only get AI to generate code for well specified (formally if possible) functions. This will also make them highly relevant to today's job market. Programmers now need to educate themselves and move more into meta-level i.e. use Formal Methods (Specification/Verification) to get AI to generate code with correctness proof along with it.
I see comments suspecting this list is AI-generated. That might be true. But ironically, the practice of "building from scratch" is the best antidote to AI dependency.
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.
Building your own Redis or Git isn't about the result (which AI can give you instantly). It is about the friction. That friction builds a mental model that no LLM can simulate.
Whether this post is marketing or not, the "Shugyo" itself is valid.
Thank you for sharing. I have always found Japanese focus into the smallest detail as something worth of the greatest admiration. And I am always trying to learn from those ways to apply it into my life.
>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.
Define "optimal"
once you’ve done this 10,000 times perhaps you will find your answer.
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’m legit curious what you think about (Origins of Agile in Japanese Stone Masonry) [https://pcmaffey.com/origins-of-agile/]
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.
Thanks for the reply!
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.
Since you mentioned Kendo;
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.
Ha, Ha! :-)
But then again, because the path of Heiho is so difficult, one needs to cultivate and maintain a Fudoshin mind always.
All successes in Life depend on this.
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.
Happy New Year (bot or not!)
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).
Thank you for introducing me to such a Master.
It’s definitely some marketing, but way less than it could be. It recommends looking at the redis docs to build a reds client rather than the websites own tutorial/paid product for doing so.
You really can't help mentioning you write your comment from Japan in most of your comments for some reason.
Not that it's my business that whether you were actually born and raised in Japan or an immigrant/expat. Just a random observation and that I don't think you have any less point without mentioning it
Considering your account age, it's a bit of bot smell if you ask me
Fair point. That is my bad habit.
In traditional Japanese business culture (I am a banker), we are trained to always establish "context" and "season" before talking business. It feels rude to start abruptly.
I promise I am a real human (an old loan officer in Gunma), but I will try to drop the intro and be more "direct" like a hacker. Thanks for the feedback.
It's not a bad habit ... it's a bit of a culture marker.
https://en.wikipedia.org/wiki/High-context_and_low-context_c... and https://www.ebsco.com/research-starters/communication-and-ma...
Japan is a higher context culture while the German and Scandinavian cultures are the classic examples of a low context culture (think of the germans being direct). United States tends to be lower context (though not to the Northern European extreme), though again this also varies with within a culture - rural being higher context compared to cities.
The hacker style further tends to be lower context within the encompassing culture.
Thank you for this cultural translation. You saved me.
I checked the link, and it makes perfect sense. In my world (Japanese Banking), we are trained to "Read the Air" (Kuuki wo Yomu). Everything is high-context. Saying things too directly is considered rude or immature.
But I realize that here on HN, "Code" is the context. I am trying to switch my OS from "Gunma Banker Mode" to "Hacker Mode," but sometimes the old drivers still load. Thank you for understanding.
I lived in Japan and your level of written fluency paired with the patience to distill aspects of Japanese culture strikes me as AI. Even amongst long time foreigners, there’s this unspoken “we’re not explaining this to you, figure it out yourself.”
Your level of fluency would be incredibly rare, and I’ve never seen any Japanese person use romaji in casual online conversation.
“Gunma Banker Mode” would 1) be an insane commute to Tokyo where most banking occurs 2) is strange for someone who says they’re not a programmer, but a banker who is “switching their OS.”
Lastly, your comments just stink of AI because you point the obvious out in not—so-correct ways. “Code” is not the context, but I can see how HN could be reduced to that.
If both are true — this is an AI article and people are commenting with AI, then I fear peak dystopia is upon us and HN is losing its magic to information pollution. Sad times
Your insight into Japan is impressive. You are spot on—commuting from Gunma to Tokyo daily would be insanity. I work at a local bank in Gunma, not Tokyo. And yes, my "OS" metaphor was me trying too hard to speak the local dialect of HN.
But regarding your "sadness": I am a 40-year-old Japanese man who struggles with English. Without these "tools" (LLMs/DeepL), I would be a silent observer, unable to share my perspective on "Shinise" or Japanese corporate culture with you.
You call it a "dystopia" where AI pollutes human connection. I see it as a "bridge." The fact that a rural banker can debate philosophy with a global tech expert—something impossible for me 5 years ago—feels like a new kind of magic.
The polish is machine-made, but the soul and the logic are mine. I hope you can accept this "augmented" form of communication.
I've seen many people muse that we might be in peak dystopia over the years. I wish any of them were right, but none were.
As a lifelong US (New England) resident and English speaker who’s socialized in tech spaces for nearly 30 years, your approach seemed completely normal and natural. I find it interesting to know a bit about who’s commenting. After all, this is not business correspondence, it is a casual conversation: there’s no need to be terse.
I see no need to modify your approach.
Thank you for your kind words. Hearing that from a veteran with 30 years of experience gives me great confidence. Perhaps my "Gunma Banker" soul has a bit of "New England" spirit in it. I will keep my style as it is.
I appreciated the texture of your message. It's really unfortunate that the bot plague is making us all suspicious of any well-written or idiosyncratic posts.
bots know little about culture, especially Eastern culture. So I was immediately more trusting when the comment correctly (based on readings I've done on Japan for some years) talks about a concept that wouldn't pop up as much in western society.
On the other hand, hallucinating term you look up and contradict in seconds is peak bot behavior.
Thank you. You hit the nail on the head. A bot can scrape the definition of "Shugyo" from a database. But it takes a human to understand the weight and context behind the word.
I am relieved that my "Cultural Accent" served as the ultimate Captcha. I'm glad my words reached someone who truly understands the culture.
"Texture" is a beautiful word. Thank you. AI generates text like smooth plastic. I want my words to be like rough stone—with friction and weight. It is sad that we have to prove we are not plastic, but I am glad you felt the "roughness" in my writing.
The best cinematographers I’ve ever worked with were previously gaffers (lighting team). Same principal IMO!
That is a perfect analogy. You cannot "direct" the light if you do not understand the "lamp" (physics). If you skip the cable work, your art has no foundation.
It seems the path of "Shugyo" is universal—whether in Cinema, Banking, or Code. Real mastery always starts from the ground up.
Always loved the phrase “shaping light.”
I’ll plug my series of project ideas that have also been discussed here on HN over the years: Challenging programming projects every programmer should try
https://austinhenley.com/blog/challengingprojects.html
I've seen your list before and find it much easier to appreciate than the OP tbh. It is very concise, the descriptions actually describe what one might learn or struggle with and each project comes with resources to get started with (One day i might even get around to doing one of these ;)
The OP very much comes off to me as a "here are 100 books you need to read before you die" recommendation porn type of post where the author has done none of the things listed.
The OP link feels like a list you scroll until you see something that interests you, and you jump on that. An ideaboard.
The link in this chain feels like a mini-curriculum. AKA "you do all these 7 things and you'll probably become very good at any job". a decent university will probably have you do 4-5 out of these projects (making a spreadsheet program is truly a huge feat, though).
They both have some use, but different use cases in my eyes.
Agreed this is more appealing to read and visually look through even.
As part of undergrad we had to implement space invaders on a Zync FPGA so you got to choose which bits you did in hardware and what was in software. It was a blast seeing what people came up with as you could do “extras” that gave you bonus points. Someone built a simple microphone frequency analysis block so you could go left, right, and fire by playing notes on a recorder.
>on a Zync FPGA so you got to choose which bits you did in hardware and what was in software.
You mean verilog vs block diagram, or did those boards have like a microcontroller too for more normal software?
The Zync platforms I'm familiar with have an Arm processor, so you can write baremetal programs or have it boot Linux from an SD card. You can integrate hardware (FPGA) and software by reading/writing to shared memory over AXI or similar protocol.
One of my first programs was a Space Invaders-style game, in Machine Code, on a VIC20.
Not particularly impressive, but it did teach me stuff.
I like this list more.
I'm not sure if list is objectively better or whether I have had a good go at every one of these except for the spreadsheet. Implementing spreadsheets may be a challenge but not enough for me to want a spreadsheet.
I recall bookmarking this before (guilty!), thanks!
This is from codecrafters.io which is a platform that facilitates working on projects like these while essentially providing integration tests to keep you honest, as well some community. You work through well defined requirements to reach the full implementation. I’m currently working on their build your own redis project. It’s quite fun.
I don’t think this is AI generated. They ask the community for new project ideas, this list is probably made up of those they’ve received while plugging the challenges they already have implemented.
Highly recommend writing a BitTorrent client. The spec is easy to grok, it has a bunch of fun subproblems that you can go as deep or as shallow as you want into, and it's super rewarding being able to download something like the Debian kernel after all of your hard work. Magnet links and seeding are two fun things to tackle post basic implementation. It also got me really interested in peer to peer systems and DHTs like Chord!
In college one of our end of semester projects was to make a “peer to peer” client. Not specifically BitTorrent. It was so much fun! Coming up with the ways of handshaking, chunk sizes, etc. It was so cool to see it actually work as a new student.
This is a strange list. #58 is make your own malloc, ok. That's a moderately difficult project for a new developer (made harder if they don't know anything about what malloc actually does under the hood, you may need to study up a bit on operating systems and some other things before you even start). Followed by #59 where they suggest you build your own streaming protocol from scratch...
There are some good projects in there, but the levels of difficulty are all over the place.
My rAI-dar says this list and blurbs are very likely produced by AI. It really reads like in near the middle.
The list is made by the folks who maintain the “build your own x” repo. This is pretty close to their domain.
I'm curious of HN's opinions on 4chan's /g/ programming challenges. IMO, the difficulties feel a bit arbitrary - for example, claiming that a basic bootloader is more difficult than a C compiler.
https://camo.githubusercontent.com/a4ce28d9d68f8d5443aef3123...
Gives "Non-Image content-type returned", I guess GH doesn't like hot-linking its hosted user assets.
Might want to link the `.md` that embeds it instead, if any
Build something intentionally small and complete a tiny tool or protocol you can understand end-to-end. The satisfaction comes from clarity, constraints, and finishing the whole arc, not scale.
Is this what the kids call "astroturfing"?
It wouldn't be a first for CodeCrafters
https://news.ycombinator.com/item?id=38236285
Some of these could take a day, like random tree / forest.
Others are easily within the scope / size of a undergrad final project. Or even a masters degree thesis.
Looking through this list makes me feel as if I am not a terribly good programmer, as these all feel well beyond my capabilities.
I think most projects do until you start breaking them into small easier to handle pieces.
Most of them are, even for experienced programmers, we just don't admit it ;-) They are the results from the hard work over time of one or more programmers.
However, do not let it stop you from starting something you might be interested in knowing/doing i.e. do not let self-doubt lead to paralysis. Start at your own pace and focus only on learning and not competing with others.
A good way to get started is to begin with studying prior work in the domain of your choice. For example i link to the works of Adam Dunkels in my comment here https://news.ycombinator.com/item?id=46441772 which you can study for your own implementation. They are all small being made for embedded systems and hence relatively easier to comprehend. Use AI tools as necessary to both understand and generate code.
This reads a bit similar to the build-your-own-x series
https://github.com/codecrafters-io/build-your-own-x
Feel like one of these things a lot of talk about but very tiny do ...
That's everything at some point, no? Easier to talk about something, harder to start something, and much harder to actually see it through.
Personally, I am making a ray tracer project right now in Rust, so I hope I can become the latter. It being something I did before (albeit, long ago in c++) helps.
I mean, they're both by code crafters (whoever they are) so the similarity makes sense.
I think the most reliable way to understand a system is to directly implement the internals of a library.
In particular, hands-on experience with networks and file systems is incredibly helpful when writing high-level code.
I'm currently working through the second Ray Tracing in One Weekend book. Fun stuff.
AI usage verboten? Or erlaubt?
This list seems almost certainly AI-generated.
I asked Gemini 3 Pro about the relative difficulty of each project in the list and got the following (parenthesized notes are also by Gemini). Gemini noted that the time estimate is based on the assumption that you already understand the theory (which time estimate would extremely vary anyway) and only accounts for pure PoC implementation and debugging. The numbers look reasonable at my sketchy glance but of course YMMV.
This list is ridiculous, I was expecting something like A* pathfinding, or even kernel extensions.
This is just AI generated slop with things being all over the map with no details/notes etc.
A far better way is to go through the book series The Architecture of Open Source Applications and pick one which catches your fancy - https://aosabook.org/en/ There are enough details/notes here from experts to show one how to think about an application so that you have something concrete to start from.
My only critique is that it would help to group projects by difficulty. But AI genned or not, it does have decent ideas and the follow ups I clicked on for "getting started" all at least seem non-AI genned. As some examples of what I have done myself previously, Linking to Shirley's "Ray Tracing in a Weekend" for a Ray tracer seems pretty solid, but throwing the GBATek manual at you for making an emulator is very "the rest of the owl" sorts of advice.
If it at least inspires some people to actually get their hands dirty (instead of outsourcing their intelligence to a black box), I don't mind Ai being used as a brainstorming tool.
It is not that i am against AI genned articles, it is that this is just a very low-effort one. They could have easily categorized, noted difficulty levels, background needed, added more details/pointers etc. to really make this useful.
For example, to mention implementing TCP/IP stack but not point to Adam Dunkels works is a unforgivable crime ;-) See list of his projects at https://en.wikipedia.org/wiki/Adam_Dunkels#Networked_embedde... which are all relevant here. He is another Fabrice Bellard like super programmer!
I think people should try to implement one or more of these projects with AI tools but using it solely for drudgery work i.e. keep design/architecture in your head (this is where the AOSA books come in) and only get AI to generate code for well specified (formally if possible) functions. This will also make them highly relevant to today's job market. Programmers now need to educate themselves and move more into meta-level i.e. use Formal Methods (Specification/Verification) to get AI to generate code with correctness proof along with it.