The Importance of Easy

I recently noticed that my usage of apps and systems is cyclical. Sometimes I use them heavily, because they're designed for a particular task that I'm doing at that time, and then I let them sit for a while. I will at some point return to the app or system when that item is again prominent.

I started to think about why in some cases I went back to the old framework and in some cases I used a new one. The answer is that I always return to an old app or system if it's really easy to do so. A simple text file system converting task lists into html, for instance, is very easy to pick up again in three months. A system that requires me to install several dependencies and requires me to use a clumsy, homemade syntax to do critical things will never be used again. If I have to create links to images in a text file by hand, writing out each one after opening my file manager, I will not return to that system for organizing my photos when I'm ready to pull a batch of them off my phone. I'll look for an alternative.

It's easy when I'm already using a system to add awkward features in order to get functionality at that time, but if I return to it later, it doesn't make sense to learn the system all over again. It's better to just start from scratch or look for an alternative that actually does what I want more easily.

The lesson: If I want to create a framework that I will use for many years into the future, I need to keep it simple. The less I have to relearn, the better. Make it as simple as possible to pick up while having as few dependencies as possible.

Some examples:

• Text files with markdown syntax. Markdown is something I use all the time, so I don't forget the syntax. Text files can easily be shared, they can be opened with any editor, and they can be put under version control.
• Conversion using Pandoc. I have Pandoc on all of my machines because it's a tool I use so often. Any reliance on Pandoc is fine.
• Makefiles. If I want to automate a task, I know I will be able to use a Makefile at any point in the future. GNU Make will always be installed. I will always be able to edit a Makefile and know what I'm doing.
• CSV files. If I want to store a small amount of structured data, a CSV file will always do the trick. It's just a text file. It's easy to read.
• Modified markdown syntax. This is an example of something that I have never been able to sustain. I have created preprocessors for markdown files. It opens the door to amazing things. The problem is that I have to install and remember how to use that preprocessor in the future. That has always been more hassle than I've been willing to go through, so every markdown preprocessor I've ever written is now dead.
• USB storage for sharing. In principle, this will work, but it just hasn't worked for me. Too much hassle to remember which document goes where, how to handle new versions of existing documents, and even where my USB drives are stored. Maybe I will make this work in the future, but I have not found the right system so far.