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.
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.
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.
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 a conversation: there’s no need to be terse.
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.
>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.
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.
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.
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’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'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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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 a conversation: there’s no need to be terse.
I see no need to modify your approach.
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.
>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.
I’m legit curious what you think about (Origins of Agile in Japanese Stone Masonry) [https://pcmaffey.com/origins-of-agile/]
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.
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.
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’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 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'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.
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.
>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?
I recall bookmarking this before (guilty!), thanks!
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 list seems almost certainly AI-generated.
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.
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.
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.
Is this what the kids call "astroturfing"?
It wouldn't be a first for CodeCrafters
https://news.ycombinator.com/item?id=38236285
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.
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.
AI usage verboten? Or erlaubt?
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.