alt Hacker NewsI quite enjoy the spirit of the article, and I believe joy in programming has become even more important in the AI agent coding age we're leaving.
However, am I the only one finding those time estimates way too short?
I'm not the fastest programmer on Earth, but I'm not the slowest either, and I think most of those projects would take me a lot more time than those estimates, specially if I'd be working only 2-3 hours per day.
I feel most of those projects would take significant time researching and learning about the subjects, before even starting to code.
Example: recently I replaced my Pelican blog by my own hacky static site generator written in Odin, working 2-3h per day, it took me 2 weeks -- and this is a simpler project than many on that list.
Replies
I see error handling as the biggest culprit here.
When I use dynamically typed languages, it's not necessarily the lack of types that make me write code quicker, it's the fact that I can call anything from anywhere with a complete disregard for whether I should.
When I'm working in statically typed languages, esp. those with explicit error handling (Go, Rust, Haskell, Odin, Zig etc), I find myself spending a lot of time thinking about edge cases, bugs etc because I am forced to do so and find myself thinking in terms of engineering rather than exploring.
I think that if you interpret "X days" as "24*X hours" this list becomes much more realistic.
For me, one of the enjoyable aspects of toy projects is that there is no schedule to meet. Which means that I can take my time. And yes, that means I take much more time than the article implies. As an examine, I've been polishing my PEG-based Turing complete language (which features both AOT-to-C and a fully featured repl) since COVID was a daily aspect of life.
I mean, all of those depend on how much was imported as third party dependency, how much was not addressed at all, and what was actually solved manually.
They're all doable if you focus on the core problems. He's got a github with many of the examples up, it's instructive on how to keep things small.
And I think it's important that (based on the code) he had a solid understanding of the problem space before starting to write code. You don't write that tight when you explore a new space.
Edit: https://github.com/ssloy?tab=repositories for the shortcut link :)
Your project is vastly more specified than a toy project, because it has a real customer (you) who will expect it to work after it ships. That expectation is what separates toys from real tools.
I bet you could write a word processor in an hour. It might only add or delete one character at a time (no selections). It might persist only to a hard-coded "output.txt" filename. You might have to kill the process because there's no quit operation. But that would suffice for a toy word processor.