Hobby project mission statements

I'm an incurable hobby coder. The rate changes depending on what's happening at work, but it never stops completely. Even during 2018, when I left Hipmunk, joined Asana, and got married, I made:

The year before that was similar:

These are not outliers. The topics change, the technologies change, but the output is consistent. Some years it's been Python, some years it's been Swift, others it's been JavaScript, TypeScript, Nim, Go, OCaml, React, Vue, Cocoa, a web API, Postgres, or Brainf**k.

I used to throw up my hands once in a while and say, “It's all too much! I have to slow down!” But I don't slow down. So now, instead of trying to slow down, I'm trying to understand myself better and make decisions about what I work on more consciously.

My projects break down cleanly into the categories defined by the contents of my ~/dev directory:

apps/             # GUI apps for iOS and Mac
cli/              # Command line utilities
games/            # Games :-)
libraries/        # Reusable libraries
steveasleep/      # steveasleep.com
websites/         # non-steveasleep.com web sites

# other stuff:
3p/               # clones of 3rd party libraries

The apps and games are ephemeral: I release them and move on. The libraries are benignly neglected, with patches getting merged quickly and releases going out sporadically. For example, I used to work on Literally Canvas a lot, but now all I do is merge pull requests and close the occasional GitHub issue.

Of all the subdirectories of apps/, games/, and libraries/, 75% have been shipped to “users” in some way as itch.io uploads, App Store apps, PyPI/NPM packages, or live web sites. Every single one has a bitchin' README.

Another way to look for patterns is to identify what's absent. There are no major contributions to third party libraries made in my spare time, though there are a few small ones. There are no Project Euler solutions, or any other “algorithms for fun” exercises. I don't use difficult-to-learn languages. And I haven't written any libraries that weren't an important building block for something else.

For most projects, I can identify the thought that made me start. Those thoughts fall consistently into two buckets. Either I'm doing a game jam with the intention of making something better than what I made for the last game jam; or I have what I think is a great idea that needs to exist, and I think I'll do a great job at making it happen.

The first bucket hasn't resulted in any stress or heartbreak. I make a bit of art and move on. The second one has all the problems. Here's why:

A Venn diagram with three circles: Things I think would be fun to make or ought to exist; Things I would personally use; and Thinks that feel like work to maintain. The intersections of 'things that feel like work to maintain' are labeled 'disappointments' and 'regrets'.

Some hobbyist programmers feel like they can never finish anything. I'm the opposite: I don't drop a project until it's “released” to some degree.

Too many times, I implement a set of neat ideas, but it doesn't feel like an accomplishment unless I commit to spending more energy than I have left. That's how Computer Words ended up. Literally Canvas was at least successful, but I still feel some ongoing guilt for neglecting it or even failing to rewrite it from scratch for the modern JavaScript ecosystem.

Here's how I want to think about starting these kinds of projects in the future:

A Venn diagram with three circles: Things I think would be fun to make or ought to exist; Things I would personally use; and Thinks that feel like work to maintain. Everything intersecting with "Things that feel like work to maintain" is labeled "Bad," things that would be fun to make are "good," and the rest of "things I would personally use" is "maybe."

Or, in “mission statement” form:

  1. I will do time-boxed game jams when I have time, I have energy, and I have an idea that motivates me.

  2. I will take on non-game hobby projects if they won't feel like work and might be useful to me personally.