Software Without Magic, Zittertagen & Marginalia

Short Stacks: the Origin

About 5 years ago I first wrote some software with the idea that this might be a career for me. I had been a Linux user for years when I found myself writing software to support myself. For the first time, I considered development as a career. And I started to drown in the sea of known unknowns. Whatever I needed to do feel enormous. It felt as though things that are basic, like serving an HTML page were an elephant I had 30 min to eat. Heaven aid me if I needed to use c, or other hard(read: compiled) languages. I had only the vaguest idea of how to use a compiler and as far as I knew `make` was a part of `dpkg’. An acquaintance in the local open source community saved me. Clint Savage showed me tools and technology that were easy to understand. He was also patient, explaining to me when I had found something I should ignore for now. Without his mentoring I never would have learned to manage the complexity in modern development.

A few years later I found Levinux. This tiny Linux image is Mike Levin’s software education project. He coined the term Short Stack to describe the environment Levinux provides. A kind of bare bones environment that I imagine the elder neckbeards toiling in when they invented the internet.

In Mike’s explanation, of the Short Stack, its defining advantage is how easy it is to learn. When you are working on a well-defined stack(Unix, vim, git & Python in levinix) there is less to learn. Less to learn means you can learn these tools deeper. Even better, if you pick your tools with care you can count on having access to them on almost any hardware. Similarly choosing battle-hardened tools can help you be sure they will stick around. These factors combine to make these skills more transferable than the framework of the week. Add c/c++ to this stack and you have some of the most valuable skills in software & IT.

These two experiences stuck with me. They taught me that my sense of mastery depends on my ability to understand the context I am working in. This idea seems obvious, almost tautological. “Developing software in a context you understand is easier than doing the same in a context you do not understand.” Seeing this written out helps us see what it implies, and how we can use these ideas to help us.

The big idea here, and one that I haven’t seen explicitly made yet is, “The easiest way to make your development environment understandable is to make it small.” A small environment is easier to learn, easier to maintain, easier to deploy, and more secure. This seems to be the underlying drive behind containers. It motivates the popularity of micro-frameworks and new Linux distributions. It has even driven attempts to re-write portions of the stack to try and make them more understandable.

This all leads us to the question, how do you get such a small environment and what is worthy of adding to your short-stack? On Monday, I will share my software short stack, and the criteria I use to decide if something is worth adding. In the meantime what are your thoughts on short-stack development, and what tools do you use that absolutely must have to work productively