Doing things the hard way

I don’t work in computing, nor am I particularly talented as a sysadmin, network admin, or programmer. The best way to solve the problems I need to solve would be to use off the shelf software (open source or otherwise) to achieve my ends and call it a day. I cannot though. I cannot shake suspicion when it comes to using technology I don’t understand (at least loosely), and I can’t come to grips with an interface that doesn’t “feel” right to me. I suppose (in spite of being a mediocre programmer) I could be accused of suffering from not invented here (NIH) syndrome.

I’ll claim (to my credit), that my inclinations are due to my love of understanding things to the basics. And that inclination has helped me when I’ve been called upon to do root cause analysis. But we’d never have any progress as a society if every time someone wanted to use an iPhone they started by building a fire to smelt some metal.

But when my skills are sufficient to avoid having to adapt a perfectly good tool and build a kludged solution, it’s kind of fun to be able to do so.

This website

This website is a kludged solution.

I initially planned to use a static site generator like Hugo or Zola (the latter because I prefer AsciiDoc to Markdown). During the process though, it occurred to me that all my standard note taking is done in Typst. I figured I’d be happier if I only had to work in one language. After a bit of research, I discovered there are a couple static site generators already working with Typst, and I actually built the first few articles with Tufted as the target. Sure, I knew how static site generators worked in general, but it seemed like well above my level to compile markup.

That’s the point I realized that Typst has a html target (albeit an experimental feature).

Looking under the hood of Tufted, I realized that it’s just using the native compiler plus a Makefile. My brain started working, and instantly sent me down this bad path.

So yeah, I (re)built what Tufted offers, poorly. It’s not all bad though! Like I said, I don’t work in the industry, so it doesn’t have to be good. It’s a text-heavy blog site with few heavy assets and no scripts, so I’m not super concerned about using too much bandwidth or having security vulnerabilities in the architecture. And I got to learn a lot from the process–refreshing my knowledge of basic *nix tooling as well as finally starting to learn how CSS works.

ASIDE

Comically though, the hardest part was learning how html works in Typst and trying to figure out how to build a site from it. Although I use Typst for notes, I tend to only use a fairly small subset of features which mostly overlap with adoc and Markdown so there was some learning in building the configuration.

Evolution not revolution

Biting off more than I can chew has led to many failed projects and starts over the years, and honestly I thought this one would fail as well. After all, how long is it going to take me breaking things when trying to add features or other types of content before I give up? Or what will I do when Typst changes the unstable method for compiling to html? Perhaps as a characteristic of greater maturity though, so far I’ve stuck with both this as well as automating the (re)build out of my home lab with Ansible.

I think though, I’ve finally started to come around to the idea of evolution not revolution in my own projects. As I’ve built out this site and the home lab, things have gotten ugly. Things have gotten messy. More than once I’ve wanted to throw it out and restart from scratch.

But back when I played video games, I also rerolled characters dozens of times before deciding to stick with one.

Someone else’s debt

There’s a dichotomy between reinventing the wheel and needing to understand to the base level, avoid dependencies, do it yourself, and then the messy reality of actually doing it. If you expecting perfection in the build, you’ll never be happy. You’ll run into all the same decisions that led to the interfaces you hate or the workarounds you don’t understand. Ultimately, whatever you built will be just as compromised as what you’re rebuilding–and probably more-so unless you’re particularly talented or have a better team around you.

And it’s the same in real life outside of software development and system administration. The successful people borrow/steal processes, ideas, concepts. They let their team build them and incorporate other people’s ideas and accept that there may not be the perfect solution, but many solutions that work. And more hands make for fast work.

And not starting to build an iPhone by refining metal yourself is the right decision.

Technical debt is going to exist, professional debt is going to exist. It’s far better to let another organization take on managing that debt that to do it yourself.

ASIDE

I’m sure there’s some Marxist economic commentary here about building on the work of others without resources flowing back to them to compensate them in a Capitalist system…

So what does that mean for me

I’m mostly writing this article so every time I think about throwing out what I’ve built, I can read it back and remind myself that the resources are already spent. If it’s a dead-end and it would cost more to keep running without the desired feature, then consider rebuilding (or better yet, use a good-enough off the shelf where someone else spent the resources). But if it’s just a bit of kludge, keep it running.

And even if it’s not invented here, be judicious about where you want to spent your limited time learning/rebuilding.