What happens when a fundamental piece of your program no longer exists? When a service you rely on is discontinued? These are problems we've only seen increase with the high amount of churn in the software world. Rather than relying blindly (or hopefully) on an external service or project, we should be diligent in our search and assessment to determine the reasonable safety of our choices.

Assessing software before committing to a given project can be difficult. Some people rely on “popularity” or usage by a notable company as positive signals to determine the safety of their choice. However, these points of data can be, and are often, completely irrelevant to your ability to keep using a given piece of software for years to come. Instead, I've found, the most important factors are size, code quality, and language. Small projects, written well, in a language you specialize in are perfect candidates. Your ability to step in and (minimally) maintain the project is paramount, lest you be left out in the cold. With this in mind, before binding yourself to an external service or project, ask yourself: “Can I manage this?”

People say “Don't reinvent the wheel” a lot. But what about building a better wheel altogether? I mean, could you imagine if we stopped with wheel v1? It's quite rare that anyone gets things right on the first try. And, even then, in the world of tooling it's just as rare that your needs will align perfectly with a preexisting solution. Every person, team, and business will have its own special set of needs. Sometimes those needs line up well enough with what is available on the market. Sometimes they won't. So, instead of settling for second-best, what do we do? Build a better wheel. You already know what you like, what works, and what's missing. Instead of having to reinvent everything, you only need to come up with a v2.

Make things that already exist and make them better. Don't let others tell you that the status quo is good enough.

I've seen this mentioned quite a bit over the last year: “Don't use Kubernetes for your blog”; “Don't use Kubernetes for just one service”; “Don't use Kubernetes for _______, you don't need it”. Sure, you don't need a lot of things.

I've chosen to run my applications on Kubernetes and, if you were turned off by the naysayers, you might consider doing so as well. Here are a few reasons for why I've decided to introduce this extra complexity:

A learning opportunity, expanding domain knowledge Experimentation Rapidly develop and deploy new applications Ownership and control over the whole system

The most important reason when making this decision for myself was “I want to learn this.” I spent the time learning how to create a Kubernetes cluster, deploy a blog, configure GitOps, etc. Because of that I built the skills to create some really useful infrastructure at my day job.

So yeah, you should host your blog on Kubernetes, you'll probably learn a lot.

Oh, and it also helps that Kubernetes is pretty fun to play around with.

I've been thinking a lot about the assumptions we make about domain knowledge when writing guides and documentation. Far too often, I've found myself needing to look up a host of terms and acronyms just to translate this jargon into plain English. Now, I've spent a lot of time doing this and gotten reasonably good at parsing text like this (often in the form of technical documentation). But, consider a developer with less experience and/or domain knowledge. They would be left not even knowing where to begin. All because the text preferred jargon over simple explanations.

I've found, where possible, complex terms should be accompanied by a simple explanation (or a link to one). That is, of course, if these complex terms are really necessary. It's not uncommon for them to be replaced with simpler, more intuitive ones. In fact, writing simpler documentation can benefit more than just novice developers. Simpler documentation can mean a faster turnaround time for newcomers to the project regardless of experience. It can also make referencing these documents easier, limiting time spent switching contexts to look up definitions/meanings. When you fail to describe things in simple, concrete terms, that burden falls upon the reader. This up-front cost to understanding your documentation should be as minimal as possible. If you force people to pay entrance fees, they'll start looking elsewhere for free admission.