The flipside of the Pareto principle

There are few things that will make you more effective than understanding how to apply the Pareto principle. This principle states that for anything you want to do, you will get 80% of your result in 20% of the time spend. If you apply this principle correctly it enables you to save a lot of resources. One of the best examples of how I used it was back in university.

In my third semester I took a course about computer networks. It's a topic I don't really care about. If it wouldn't have been mandatory, I wouldn't have taken the course at all. But since it was, I just didn't attend the lectures and half-arsed everything else about it. When the time for the exam came I knew almost nothing of what I should have learned about. To make things worse, this course was very material-intensive. Some of my fellow students had studied two weeks for the exam. I wasn't ready to do this. All I wanted to do was to pass the course with as little time spend as possible. My grade didn't matter. So the afternoon before the exam, I reviewed the exams of the previous years and searched for the parts that were often occurring, brought the most points, and were the easiest to answer without having much context of the remaining topics. That was all I needed to pass the exam.

This example demonstrates that the Pareto principle can be helpful to cut corners, eliminate what you don't care about and be more effective in following your goals. The principle's flipside is that in everything you care about, there will be a few tasks with very little effect that are still necessary and will take a lot of time to accomplish. I was vividly reminded of this yesterday.

I'm hosting this website on my own server. I have also written my own site generator for it. So far, its setup has been rather minimalist. Whenever I had finished a post I uploaded it to the server and manually regenerated the website. This took about three commands and two password prompts. While it worked, with writing a new post every day it became tedious. That's why I decided to rework this setup to regenerate my website automatically whenever I publish a new post. Using a git repository this is relatively straight forward. Still, I had to change a few things in my SSG and needed to figure out how to connect the pieces. All in all, it took me around 4-5h to have a first version that was (almost) working. It got messy when I tried to install my own git server.

In theory, hosting your own Gitlab instance is easy. It's open source software, available on most package managers and takes only a few commands to set up. In practice, the OS on my server hadn't been updated for a long time and was now too old to run the newest Gitlab version. I had never bothered with upgrading my server, because, well, sysadmin stuff is annoying. When I tried to do it now, the normal procedure for it wasn't working. I don't know whether this is because my OS was too old, or because I had broken it through some configuration black magic I had done a while ago when I (unsuccessfully) tried to install some other piece of software. Starting a more manual upgrade worked, only for it to fail midway and to leave the server in a broken state. Reverting the changes the upgrade had made so far was impossible. At this point, I had worked the whole day on reworking my setup and wasn't in the mood to continue experimenting. So I used a backup and reverted everything I had done so far.

This leaves me with the task to install the OS on my server from scratch and reinstall all services I had running on it. Expected time needed: The rest of the week. Benefit of doing so: I don't have to use github for hosting my blog's repo. In moments like these, I'm wondering why I'm even bothering with self-hosting my website.