Zero Waste

As the proverb goes, “A bad workman blames his tools”. And in software, there are far too many complainers.

A lot of “advice” aims at making you feel inadequate about your technical choices: “Stop using \(x\)”. “I did \(y\) and you should too”. It may feel tempting to heed these warnings, more so when they alert you about techniques and tools you’re unfamiliar with. However, say what you will about people’s motivations, I started regarding this sort of inflammatory rhetoric as a clear sign of incompetence. Following are more level-headed principles that I began introducing in my practice instead.

I pay attention to how I like to work. I noticed that small frictions have a tendency to frustrate me over time. The more frustration I accumulate, the harder it gets to focus on the work. Emotional perturbations will do that to you. As a rule, I customize my tools to fit my workflow and habits. As an example, I find multi-tasking distracting. For this reason, when I’m using Vim, the text editor I work in, I prefer using buffers rather than tabs. Therefore, I set my configurations such as to help me manage a workflow centered around buffers. I look for ways to open, navigate, close, and edit buffers as quickly as possible, with as minimal fuss as possible.

Once I have set a direction for how I want to work, I adapt my workflows to take advantage of what my tools afford me. Picking Vim yet again to exemplify this principle, I would spend time learning about how Vim buffers work, in detail. I made the error before of settling with shallow understanding of my tools, and regretted it. I would create clunky workarounds to sidestep problems that a tool solved with specialized features. But because I skimmed the documentation, instead of reading it properly, I would either forget or miss this information entirely. There’s nothing worse than knowing a little about something, especially if you’re going to apply this knowledge often. Reading documentation and becoming proficient with the standard libraries of whatever programming language you use is a priceless use of your time. Smarter people than me have inked the answers to questions I wouldn't even know to ask:

I learned to be wary of the urge to pursue new, shiny toys. Every tool you add to your toolbox comes with cognitive debt. A rule I impose on myself is that, if I don’t use a new tool, or workflow pattern, often enough (which is admitedly a vague criterium) it gets discarded within a month. This rule has highlighted for me how many dangling, unneeded things I was dragging along for no other reason besides "I might need it some day". That day never comes. Now, if I read my configuration files and I can’t recognize what a given line does, or if I can’t recall why I downloaded a specific plugin, I remove them.

Lastly, I figured that familiarity beats ornate solutions. That is, crafting a comfortable, simple, and bog-standard environment in which to work is more important than creating ever novel and elaborate schemes to fit incompatible things with each other.