The creative agency of small projects
Since I moved out of the startup world I've exclusively worked on small projects. Niche, simple tools packed with love and attention to detail. I've written about my approach to building, and how it impacts my life and outlook.
Today, however, I want to write about a less-obvious benefit of building small: The agency to be more creative.
I used to frequent game-jams back in the day. At the beginning of a jam teams are presented with "the theme". This is a mechanic, or even a single word, around which your game is to be built. It's a seed from which to grow your own novel idea.
For example, one game-jam I attended back in 2018 had a single word theme: "waves". During this event I saw interesting interpretations and neat ideas ranging from a game about surfing (a pretty literal interpretation, for sure) to one about trying to figure out if a person on the other side of the street is waving at you, or someone behind you (where you lose points if you awkwardly wave back). There were a few that played with light and sound as well, which I thought was a cool "waves" interpretation.
Our game was called Wheelchair Wizards, where 1-4 players control wizards in wheelchairs (moving around by shooting fireballs). All the wizards spawn atop a tower and have to hold off waves (yeah, it's a pretty loose interpretation) of goblins crawling over the crenelations. We had a great time building it and managed to nab the "most fun" game award for that particular local jam.
Circling back to building non-game products, having something small creates space to play with new ideas. The first reason is that your "theme" is set and (hopefully) well defined. For example, it's difficult to pin down what the "theme" of Wordpress is. Whereas Bear's theme is simple "a super fast blogging platform that gets out of your way".
The second is that experimentation isn't expensive (both in terms of time and money) when you build small. A new feature only takes a day or three and many can be easily abandoned. Most ideas aren't good. Other times you strike gold and merge to master. Now that's satisfying.
Then there are self-imposed constraints. At some game jams you can choose to do these optional constraints to receive extra points. Think of them as "achievements". Here are a few examples:
- Your game must be controllable with only one button.
- You can only use a 2 bit colour pallet.
- Local multiplayer.
- All sound effects need to be voice recordings.
This adds delight to the building process. Many issues are simple to solve by breaking one of these constraints, but much less satisfying.
Here's how I used self-imposed constrains on Bear:
- No client side Javascript.
- Synchronous everything.
- Pages need to be under 5kb.
- It needs to run on any device (including my Kindle's browser).
And I've held pretty tightly to these constraints. Even Bear's analytics system is fully server side rendered using SVG graphs. Yes, there's technically a JS library for that, but then I'd be cheating.
Am I saying that this is the optimal way to build software? Certainly not. Is it the way I like to build software?
Absolutely.
Finding joy in what you're working on is the difference between a product that feels loved, and a sterile tool. It's the difference between a hand-made teapot with the oceanic glazing, and the white one you get from Ikea.