Making my working environment portable

View source | View history | Atom feed for this file

Just some notes for now.

Particularly when editing text, I find it incredibly irritating when it takes a lot of time to go from my thoughts to the form of text on the screen. Learning Vim has helped with this, possibly to a great extent (it is difficult to know because I learned it in small increments – being forced to use a primitive editor and finding the experience jarring perhaps gives a good idea of how much I have internalized).

It is possible to detect each cause of editing slowness and add some speedup each time, but the writing of mappings, plugins, or of researching them itself takes a lot of time. The plugins could have strange bugs in them that could screw me up down the line (in some unforeseen way), which is rarer for the “core program”. I’ve found it difficult to anticipate in advance what kinds of configuration saves me time in the long run, which ones I decide to stick to, and which ones I end up forgetting.

Software configuration is also incredibly fragile. Some examples:

In a “getting things done” mindset, I tend to view the act of configuring software similarly to writing software or reading information or hiring someone. There is some cost to me in the process, and hopefully I get something useful out of it that helps me accomplish my goals. What is different? With software configuration, the cost involved is mainly the research and experimentation time, as well as some frustration when the software doesn’t work after configuring. The mental experience is also a little different, because I have to deal with idiosyncrasies of the configuration API provided by the particular software in question.

TODO talk about “configuration bankruptcy”; I’ve encountered the concept most frequently as “.emacs bankruptcy”.

More generic software rant: I encounter a lot of small software-related nuisances in my daily life. And, having learned how to program, I know that, theoretically, I could spend time digging into each problem, contacting the software author or whatever (most of the software I use is free software and actively maintained, so this is possible), filing a bug report or working to trace the error/fix it. But would I do that for such a small nuisance? For any particular nuisance, it seems like the total amount of time lost from it is less than the expected time it would take for me to fix the problem. So in the long run, the problems that get fixed are the serious flaws, or the ones that are fun to fix, or that seem easy to fix, and so on, and I’m left with generally good software that just doesn’t work quite right.

Aside: the “SAAS approach” to this problem is to create one instance of the environment, which eliminates the need for portability.