Learning to Simplify

When I first got this writing prompt, my mind immediately started thinking stuff like, “What tech have I learned this year?” But this post isn’t really about tech, because I think what I’ve learned the most about building websites this past year is simplification.

This year, I’ve learned that keeping it simple is almost always the best approach. Heck, I’ve been banging that drum for a while, but this year has really solidified those sort of thoughts. I’m trying to think of a single instance where a complex, technical issue has arisen this year, where the end-solution didn’t come about due to simplification, and I’m coming up blank. Sure, ideas almost always start off over-complicated, but I’m learning more and more that slowing down and refining ideas is the best approach.

Brendan Dawes created this great piece of art, and coincidentally, a copy of it sits on my wall. I think it illustrates my working process perfectly and acts as a constant reminder to refine and simplify.

I run Piccalilli and released my first course this year. I really wanted to self-publish that material, too. Sure, keeping it really simple would have me publishing the course on an existing platform, but I had some red lines. The first being that I had to own everything because if a provider or platform turned out to be ass-hats, then I’d be in a pickle.

Another red line was that my content had to be written, rather than videos, which again, makes owning my own content important, because some platforms can pull the rug from under your feet. A good example is Medium’s ever-changing content access rules and inconsistent paywall behavior.

Finally, the red line of all red lines was this: the content had to be fully accessible and easily accessed. You might be thinking they’re the same thing, but not quite: the easily accessed part means that if you buy content from me, you sure as heck will get to it with as little friction as possible.

---

This loops me nicely back to keeping things simple. To make access simple for my valued students, I needed to simplify my approach to them accessing content, while locking people out who hadn’t purchased it. My immediate thoughts — naturally — went into some complex architecture that was extremely smart™, because that’s what we do as developers, right? The difference this year versus previous years is that I forced myself to simplify and refine because I wanted to spend as little time and energy as possible writing code — especially code I know is going to haunt me in the future.

So, again, thinking about these red lines, the big caveat is that currently, my site runs off a static site generator — Eleventy, naturally — and my need for simplification along with this caveat led me to an obvious conclusion: use the platform.

In short, I used Service Workers to give people access to content. My site builds twice on Netlify. Once is what you see, over on piccalil.li. But there’s a secret site that is all exposed (it’s not really, it’s like Fort Knox) that has all the content available. When you buy a course, my little API scurries along to that site and finds all the content for it. It then pushes that down to you. Then, the platform takes over because I use the baked-in Cache and Response APIs. I create a Response for each lesson in the course, then stick it in the Cache. This means that whenever you go to a lesson, you get that version that was previously hidden from you. The added bonus to this is that the content is offline-first, too. Handy.

Sure, this solution relies on JavaScript, but heck, not much at all — especially when you compare it to even the simplest projects that produce extremely JavaScript-heavy outputs, like Gatsby et al.

Using the platform is super low maintenance because, y’know, it’s all baked into the browser, so it doesn’t keep me up at night, worrying that it’ll suddenly break if a rogue developer deletes a package. I could have also put together some galaxy brain stuff but that has a huge risk of creating technical debt and breaking at least one of my red lines: make content fully accessible and easily accessed. The platform again, wins.

If I push a big ol’ bundle of JavaScript down the pipe to a low-powered device and/or a slow connection, the chances are that content will not make it, or if it does, it will likely fail to parse. That alienates a lot of people which breaks red lines for me. Sure, building the site with this technology would keep it simple for me, as I wrote it, but utilizing the platform keeps it simple for everyone — especially me, when I need to maintain it. I’m digging that, a lot.