Finishing side projects

I’ve always taken pride in finishing side projects. I shipped a tiny one recently, and have a few more in the works.

The challenge of side projects shifts as I change and the world changes around me. These are the principles and pitfalls I’ve encountered recently.

Don’t get lost in asking why: “for kicks” is reason enough

Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.

Remember that quote from Dr. Ian Malcom in Jurassic Park, remarking on the reintroduction of dinosaurs to the world? It’s become a bit of a meme in technology, applied to both the useless and the evil. The morale is that you should ask why.

Honestly, though, don’t. If you’re building a company, ask why. If your side project involves CRISPR, always ask why. If your project is at Palantir, quit. But if you’re making something to explore an idea, to learn, to have fun, don’t fall victim to this ethical analysis paralysis.

It’s a balance: learning through play and by making things requires some creative freedom, some ability to fail and get up. That permission isn’t a blank check that you can apply to companies or to mature projects that continue to ignore their ramifications. The internet once did, and maybe still does, offer a space for experimentation – the equivalent of college, where you can write a bad essay or explore a wrong idea before being exposed to public scrutiny.

Don’t plan too much or you’ll talk yourself out of everything

I’ve become the kind of person who takes paper notes and gets a little thrill from planning things out: an old person. I tried to apply this idea of ‘organization’ to new projects, though, and quickly found the pitfalls. I’d start a fun project - for example, a tool that automatically finds dead links on this website and offers to re-link them to archive.org.

That’s fun for me. But, writing it out, I started thinking about all the corners and hard parts. How do I deal with websites that are intermittently down? What about caching results so the tool doesn’t have to re-visit every website every time? Should it remove the archive.org link if a website goes back online?

I was facing the downsides before I even had a chance to enjoy building, before I had chosen a color or written a line of code. And I was staring up at the fully-realized mountain of tasks I had written down in a notebook. It sucked.

This is part of the Yerkes-Dodson Law – that being a little nervous helps, but true and complete anticipation decreases your performance.

Thinking back to the many projects I had written without an ounce of planning - geojson.io, simple-statistics, documentation - I certainly have regrets, so many regrets, about some of their implementations, but could I have sussed out a correct plan at the beginning and avoided rewrites and flaws? Not really. Some would have benefited from an ounce of planning, but with any more than that I might’ve scared myself off.

Strike a balance between using your core skills and learning new ones

Think of everything you know well, and a few related skills or techniques that are one step away. And then a few that are very new and where you have no familiarity. Draw a line around what you know, choose one or two things you’re familiar with or don’t know at all, and try to work with that.

For example: my last project mostly used a stack I was confortable with - Netlify, tachyons, Node.js. But it was my first time doing spreadsheet-driven development in the style of Pieter Levels, and it turned out to be a good mix of old & new.

Using only your core skills all the time is stagnation. Not using any of them is a guarantee of anxiety and a curse for productivity. Figuring out how to blend what you know and what you don’t – and when you have the mental space to learn – is key. There’s nothing wrong with having a tried and true set of tools that you stick to.

Thanks Omar Rizwan for informing me that the motivation curve is what I was encountering.