Last week I shipped a redesign of my personal website
, a project that started in September and took nearly two months of working nights and weekends to finish. Here’s the beast of a pull request
that brought it all together for the code-curious among you.
I think the only reason that it’s worth talking about this redesign is because it’s just so over the top, and so over engineered: User authentication, comment systems, email notifications, user preferences, daily digests, end-to-end continuous deployment, caching…a classic case of someone being too preoccupied asking themselves if they could that they didn’t bother to ask if they should.
All of this work for a personal website that is, zoomed out, a handful of text files as blog posts, a handful of links as bookmarks, and some pretty CSS to make it feel like an app. Over-engineering things is fun
But now: this website is my own little corner of the internet, where I know how everything works, and I know all of its little idiosyncrasies. Everything that I love about it is my fault. Everything that I hate about it is my fault. And I’m the only person on the planet who cares enough to tidy things up, to make it better, to shape it, evolve it, or…if it all becomes too much, I can burn it to the ground.
This is going to sound crazy but: the shape of my website sits in my mind like a physical thing. The codebase is a home, and I know what the walls feel like. There’s a texture here, and you have to be careful for the splinters if you tread carelessly through that room over there. There are dark and dusty rooms where I’m afraid to go. There are details too small to notice from a distance, but become apparent once you step inside and look up close. There are beautiful parts that I’m proud of, and I think other people will like them, too.
And so I turn this home over in my mind, and daydream about how to smooth the edges, simplify it, and refine it. I’m picturing the next room I want to build, but I’m concerned about the state of disrepair of the pipes straining in the walls.
Is this place fit for living? No, not yet…
This right here — this turning over in my head of an object where I know the thing, I can feel it, I can hate it and love it simultaneously — gets at the core of why I love building software at all. Code and pixels materialize in my head and create an invisible bridge between the physical and digital, a bridge to a place where I have superpowers. Anything is possible. And everything is disposable. This is exciting and deeply sad at the same time.
This home will soon crumble into dust…
Here are a handful of ideas that have been buzzing around in my brain that I’ll be diving deeper into in the future:
→ Idea: The status quo of software is generally disappointing.
Let’s start here: the status quo of software is generally disappointing. Every tool that I use either has too many features, and is overwhelming and confusing, or has too few features, and leaves me feeling like I’ve made a compromise. And it’s simple to see why this is: nobody builds software for me. Companies build tools for everyone. Or if not for everyone, they build for a type of person. Tools for developers. Tools for designers. Tools for investors. Tools for writers.
The problem is that nobody is building tools for my particular, individual, intersection of all of these interests, and so I’m forced to Deal With It, or stitch together apps and workflows into a messy web of bits and URLs and…it all just feels so sloppy.
→ Idea: Building your own tools leaves no-one to blame but yourself.
When I use bad tools, it’s nice to have someone else to blame. Ugh, iCloud is so janky! Ugh, I can’t believe how much crap Google Maps stuffs on to the screen these days! It’s easy to have someone else to blame, and easy to have an excuse for why modern software feels so disappointing: it’s always someone else’s fault.
But building tools of my own leaves me with no excuse. Everything that’s good: my fault. Everything that’s bad: also my fault. Everything that’s frustrating, or confusing, or buggy: I’m the only person who cares enough to fix it.
→ Idea: Software-for-one is a playground for rule-breaking.
There are a lot of rules I follow when I’m building things for my day job. We build things in specific ways with specific processes for a certain kind of person that has some baseline expectation for how software should work. It has to scale. It has to Just Work, because someone depends on it to get their job done.
Then suddenly, I’m building something just for myself and…it doesn’t have to scale. It doesn’t have to work on that kind of device. It doesn’t have to account for this kind of user input. Nobody’s livelihood depends on it.
So I can break the rules and build the parts that I find most interesting. And the way I use a computer might be slightly different from the way someone else does, but it doesn’t matter too much. This is for me, and I can break any of the rules to make things feel just right.
→ Idea: Building your own software changes how you perceive all software.
Once you start building your own tools, a mind-warping parasite infects all of your future interactions with software. This parasite has made me simultaneously more empathetic and critical of the tools I use. Some app breaks, or crashes, or doesn’t respond exactly how I expected, and I can squint and see how hard that thing must be to build. It motivates me to send feedback to the developers, or open an issue, or message someone on that team.
Nothing simple is easy.
→ Idea: When should a personal project be open source or private?
While I was rebuilding my site I thought I’d make the repository private. It really became a battle with my ego. I wanted to be precious about my code. I didn’t want to see a ripoff deployed somewhere without attribution. I was protective of my work, selfish, and mistrusting of the world.
Ultimately, I kept everything public
but they assume is working as intended.
→ Idea: How to decide when it’s better to build or buy your own tools.
I have to remind myself often why I’m building a tool in the first place. Most of the time, it’s just because it sounds fun, and I want to learn something new. Ultimately there’s no end goal here with my personal website — I love the process. If there were a goal, then the calculus shifts a bit when deciding whether to build or buy.
For example, I pay $300 per year for a Ghost subscription. That sounds really expensive. But then I spend dozens of hours building my own interface on top of those posts, and suddenly $300 becomes a rounding error on my time. So if the goal was to blog and write more, Ghost is cheap. If the goal is to learn and have fun and build something for myself, then it’s not practical to try and convert my time spent into a return on investment.
··· More to come
If these ideas and topics sound interesting, subscribe to this newsletter or follow along via RSS on my website