I know that on Friday I promised you all that I would be sharing my own software short stack. But as I was trying to build and document my stack I found myself fighting against it. My initial efforts to define a short stack borrowed from suckless & considered harmful.
Both of these lists advocate small composable tools. Something I have been well convinced is a virtue in a toolkit. Most of them are written in C or similar low-level language, and are explicitly trying to be both simple and fast. When I tried these tools however I found that they got in my way.
The suckless tools I examined were close to the metal, written in C, and blazing fast. Both ST and DWM brag about how few lines of code they have. As a direct result of this both of them demand that you already know C to do any customization at all. ST lead me on a wild-goose chase tracking down behavior of my backspace key. DWM demanded I interact with the keyboard at a low level if I wanted to customize it.
The ‘considered harmful’ suggestions were often more confusing. Quite often, they seem to be pushing Plan 9’s way of doing things or proposing we adopt new ways of doing things even though a well supported de-facto standard is widely used. One particularly egregious example suggested that we replace `head` with `sed 11q`. That does work, it’s clever and demonstrates that the inventor understands an existing tool well. It also demands that a new user learn a bit of sed or accept a magic incantation, to something quite basic like peek at the top of a file.
Both lists inspired my explorations of Short Stacks, and in the past few weeks I’ve read through both sites quite often. They also both demand that users be quite advanced to be very productive. After a few weeks trying to adapt to them I realized that I was wasting time. Instead of picking a set of tools to use and solving problems, I was shaving a yak. To make things worse, this yak did not need shaving!
I already have a mostly functional toolkit that does all of those things. My terminal already gives me the *nix, vim, git, python, short-stack I cited Friday. I could have very likely already solved a couple of interesting side-problems in Python with the time I’ve spent yak-shaving and picking tools.
It is easy to get lost finding just trying to use your tools, or how to do something you know is simple. Both of these delays are a kind of mental stack overflow. Instead of solving the problem you are recursing to solve the blocking meta-problem.
I had reached for these tools after getting fed up wit .net and it’s associated tools at work. Visual studio is a great IDE, but it is anything but a short stack. Particularly after you install the all but essential extra tools: Resharper, Web Essentials, Fiddler, Postman, Powershell, Powergui, and so on. Even on my beefy workstation I spend a lot of time waiting for things to load, compile, or update.
In trying to explore alternatives to the high-level but slow tools I use at work, I ran into a conflict. There are at least two ways to measure the depth of a stack. The first is ‘distance to metal’. How close is your work to the actual platform on which your solution will run? The second is ‘conceptual RAM’. How many things do you have to keep track of to complete your goal?
These ideas of stack depth have different implications when building your personal workspace. Noticing these and working out these implications is what led me delay defining my own base stack. Whatever I stack I define and put the effort into automating needs to meet several needs. It must be fast. Even on my wimpy Chromebook 2. It cannot steal mental ram from the task at hand.Nor may it lead me on a quest for the finest Yak’s Wool.
For the moment, my stack will remain manual and tied to the web. I will keep using my crouton as a *nix shell, using my adapted dotfiles, on my Chromebook to build my side project. Do my writing in Google Docs, and publish on WordPress. I’ll also be trying to solve my idea of stack ranking and ELO to help estimate task & issue priorites in Python over the next week.
I will also continue to work on defining a “basic short-stack” that it is worth automating by next Monday. Until then what tools have you used that demand massive amounts of mental ram, or despite being nice are just too slow to use day to day?