Doing Things That Scale

This 2020 blog post by Tobias Bernard has been sitting in my read-list for several weeks now while I ruminated over what he says in it.

I stopped doing all these things at various points for different reasons, but underlying them all is a general feeling that it’s taken me some time to figure out how to articulate: I no longer want to invest time in things that don’t scale.

…

Not only is it highly wasteful for me to come up with a custom solution to every problem, but in most cases those solutions would be worse than ones developed in collaboration with others. It also means nobody will help maintain these solutions in the long run, so I’ll be stuck with extra work, forever.

While I’m not (currently) a Linux user, I can identify with him on opting for a more straightforward macOS setup over one that’s customised to heck and back.

And while I’ve not often contacted developers to suggest changes and improvements in the past, that is definitely something I will try to do in the future.

I had to laugh at the example of ZSH — I started customising my setup a year or two back but never actually finished. (It works fine, but I’m sure I’m not using all the features.) I may check out fish, or start over with a new ZSH profile without plugins and just a few options and defaults added.

But the main reason it has taken me so long to write a blog post about this is because I was procrastinating over whether to press on with this current WordPress self-hosted blog or switch to a static site generator. I’ve now decided that the benefits I get from WordPress outweigh the niggles, so I’m going to stick with that while I use a local WordPress installation to explore block-based theme creation. The alternative would have meant spending a lot of time learning, say, Hugo’s way of generating layouts plus how to get the output online.

Yes, I might have been able to share what I learnt working with Hugo, and perhaps help others. But I’d argue that learning how to work with what I’ve got now (WordPress) and share that knowledge will help a lot more people.

I’ll close with the last two paragraphs from Tobias’s post:

The free software community tends to celebrate custom, hacky solutions to problems as something positive (“It’s so flexible!”), even when these hacks are only necessary because things are broken by default. It’s nice that people with a lot of time and technical skills can fix their own problems, but the benefits from that don’t automatically trickle down to everybody else.

If we want ethical technology to become accessible to more people, we need to invest our (very limited) time and energy in solutions that scale. This means good defaults instead of endless customization, apps instead of scripts, “it just works” instead of “read the fucking manual”. The extra effort to make proper solutions that work for everyone, rather than hacks just for ourselves can seem daunting, but is always worth it in the long run. Just as with accessibility and commenting your code, the person most likely to benefit from it is you, in the future.

Thank you Tobias for your thought-provoking post!