After my last blog post about Hurl, someone asked me, and I quote: "... why?" The simple answer is "for the joke." But the longer answer is that useless software is a fantastic way to explore and experience the joy of computing. Play is an important part of exploration and joy.

As technologists, we spend our days mired in making useful things. Software engineers write code to solve real problems. Computer scientists research problems to produce novel, real results. Technical writers write about actual technology, write real documentation, and more. The list goes on, and the common thread is that if we do technical work, we do it in the context of something useful.

Many people get into programming because it in some way sparks joy for us. It's 100% valid to be a software engineer for the money. That's certainly part of why I gravitated toward it as my career. But with so many career paths available to would-be software engineers, I suspect enjoyment of the craft was at least part of the decision for many of us.

When you spend all day working on useful things, doing the work, it's easy for that spark of joy to go out. And having it go out? That's a fear I've heard from some folks who are switching careers or making programming more of a focus of their daily work. When you have to do things, those daily pressures tamp down on excitement. Everything you do is coupled with obligations and is associated with work itself.

You lose the aspect of play that is so important.

Writing useless software is a great way to free yourself from those obligations. If you write something just to play, you define what it is you want out of the project. You can stop any time, and do no more or less than you're interested in. Don't want to write tests? Skip them. Don't want to use an issue tracker? Ditch it. Finished learning what you wanted to? Stop the project if it's not fun anymore!

Here are some of the "useless" things I've written in the past few years to play:

• A terrible chess engine and UI, riddled with bugs, which taught me about GUI programming and game programming, and led to a more thorough understanding of how chess engines work.
• A key-value store which implements part of Redis's API, which taught me about systems programming and how to write more efficient code.
• A wake-on-LAN utility, which taught me about how WOL works and how Rust network programming works.
• A visualization of some chess games, which let me explore producing art with code and play with ways to visualize a game I love.
• A chess database, where I learned a lot about bitmaps and database internals.
• An LLM-based tool that "mansplains" what a command does
• An unfinished implementation of the POP3 server-side protocol, where I was learning about the protocol, and had a lot of fun thinking about what a POP3-based app would be like. Instead of a web app, maybe we should make email apps!
• Worked through "Crafting Interpreters" to learn and have fun writing something in Rust! (Also, a bit of wanting to see if I can match or exceed my friend Mary's implementation's performance.) This taught me a lot about interpreters and compilers, but the goal was just to enjoy it.
• Worked through half of "Mazes for Programmers" in Rust, and abandoned it when it became a chore. It was fun, but I didn't want to go further.

And more small scripts I'm not remembering, to play with ideas and concepts and try things out. I think being able to take our craft less seriously and try out things that are "useless" is a tremendous way to learn and have some joy from just playing with computers. It's something I try to do a lot.

So, that is ultimately the "why?" behind Hurl. It's a form of play. It's not useful, but I'll probably learn something doing it, and I will definitely have fun in the process. Play is important, and I think we all deserve to play more.