I agree 100%.

Here’s why I prefer making “useless” stuff: https://austinhenley.com/blog/makinguselessstuff.html

And my list of similar projects: https://austinhenley.com/blog/challengingprojects.html

I want to do a database and then something involving genetic algorithms next. If I have infinite time, another video game emulator too.

Like most estimates, these seem off by about 3x. At least if you're writing it for the first time.

I have never been paid to write code, and my formal CS education is limited to AP Computer Science, and a one-credit Java class in college.

I wrote 20 years ago a backup script implementing Mike Rubel's insight <http://www.mikerubel.org/computers/rsync_snapshots/> about using `rsync` and hard links to create snapshots backups. It's basically my own version of `rsnapshot`. I have deployed it across several of my machines. Every so often I fix a bug or add a feature. Do I need to do it given `rsnapshot`'s existence? No. Is it fun to work on it? Yes.

(I've over the years restored individual files/directories often enough from the resulting backups to have reasonable confidence in the script's effectiveness, but of course one never knows for certain until the day everything gets zapped.)

These are all great projects! When I find myself getting burnt out in my job I find that writing a little toy project usually helps be get back some spark. Some projects that weren't listed that I've enjoyed:

- GUI based bot for a small video game

- raft consensus algorithm

- ray casting

- simple b-tree or lsmtree storage engine

I'll also second chip8 emulator as being a good quick fun one! It helps there are ROMs that help quickly validate your implementation also (https://github.com/Timendus/chip8-test-suite)

This list reminded me of Build-Your-Own-X (https://github.com/codecrafters-io/build-your-own-x)

My personal insight on this: toy projects are fun not because they're small in scope, but because there's no downside to failure.

Production/professional software has significant downsides when they fail (customer unhappiness, professional performance and incentives, etc).

It's also why toy projects open up very innovative pathways. You tend to not be conservative with them, and once in a while something amazing ends up working. Bringing this non-conservativeness to professional software is a skill once developed makes your growth shoot up.

I, too, had infite time once, and loved spending most of it on coding.

I built a toy OS[0], compiler[1], crypto library[2], a bunch of other stuff, and had a blast.

Now, I have more obligations and more non-coding fun stuff I want to do.

For the programming that I do want to do, I don't particularly enjoy tracking latest breakages from upgrading a random React Native library or drinking from a Kool-Aid firehose of a VC backed open source solution that's going to get acquihired or pivot in 6 months.

I enjoy working with LLMs in turning silly little ideas I have into toy products without grinding through incidental software complexity swamp that is modern software engineering.

[0] https://github.com/senko/Hasenpfeffer

[1] https://github.com/senko/calcc

[2] https://github.com/senko/CyFER

This definitely resonates with me. One of my favorite pasttimes is to code away on a 2D multiplayer RPG engine, and I've ended up doing at least a few of the projects on this list as part of that (ECS framework, voxel renderer, physics engine). Integration with a scripting engine like Lua is another fun one for a list like this, especially if you try to do it in an idiomatic way for your main programming language and/or leverage code generation and metaprogramming.

One thing I've found I enjoy is working on a larger-scope toy project composed of many loosely coupled systems. It works well for me because no matter what type of project I'm interested in working on, I can usually find something applicable within the larger project. Currently on my to-do list are behavior trees and procedural terrain generation, and honestly I don't know how I'm going to decide which to do first.

While the list includes tools which are at the most basic level - how many actually have built their own editor? - I do agree with the author. It teaches you skills, which are great for any software project.

Every time I learn a new language or concept, I try to apply the principle of achieving a basic task with it.

When the meteor framework came out, I created a bullshit bingo in multiplayer mode. People could create their own bingo cards or use predefined bingo cards with business bullshit terms. Anybody worked in a big corp and had a boring meeting? The multiplayer bingo for the win ;) It was never made public, just a proof of work and to get a grasp on how to use the framework, but had a few chuckles

I had done a few related things to some of these, in some of the programs that I had written. I also think that there is a benefit of emulation especially if it is not overly complicated, that the program can run on many computers. I also think that there is the benefit for the computer to be understandable. I may later consider some of the other stuff, such as game that only persists 64-bits.

> Properly handling unicode, syntax highlighting, cursor movement, multi-buffer support, panes/windows, tabs, search/find functionality, LSP support, etc.

You do not need all of these things to make up a text editor. What I would like to have better is a text editor and GUI with better support for non-Unicode text. A feature they didn't mention, that I find useful, is being able to send some text to an external program and replace it with the result; I do sometimes use this feature in vi.

https://3nsi2a2rf4.alternative-accounting.com/game

on mouse stop move over canvas

wont be available for long, that's my idea of toy software, vibe coded the smallest multiplayer game I could think of, about 75% complete. Just taking territories and there's a link to the IP address so you are on the team of the country ip address belongs to. Not smart enough for real game development so have to live within limits of my own abilities.

Most difficulty and time estimates are random. Chess engine 2 days? Like a really shitty chess engine maybe. Regex engine 4/10, 3 days. Again a really shitty regex engine. What's the point of doing a bunch of projects in a really shitty way?

Hell yeah! Ive been off and on working on a version of a 2D physics engine in the form of a zero-player game, been a great joy to hack away at over 2 years.