If you haven’t read about “Taco Bell” programming I suggest you read Ted’s post in full. It’s short and enlightening, trust me.
Otherwise, here’s the basic idea:
Every item on the menu at Taco Bell is just a different configuration of roughly eight ingredients. With this simple periodic table of meat and produce, the company pulled down $1.9 billion last year.
The more I write code and design systems, the more I understand that many times, you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set.
On paper I’m not a “developer,” but I can compile a Linux kernel, patch C code, script in Ruby, Python and get around any repo to read and/or make changes. Having spent too much of my career in Apple device management, most of my time revolves around shell scripting, be it POSIX sh, Bash or more recently zsh. I often get laughs, pity or looked down upon when I mention this amongst other tech workers.
However, from my point of view, I pity them. Why? Because I know that my scripts will work out of the box on every Mac. Hell, most will run on any Unix-based system as long as I’m not using a Mac-specific binary or file path. I have no need to include loads of 3rd party libraries, dependencies or runtimes prior to executing and as a bonus there’s no chasing trends.
There are times I want to use Python simply for a change, but alas, with my knowledge of basic Unix and shell, I often know how to solve the problem in a few lines of Bash.
This leads us to the next bit…
Taco Bell Programming is about developers knowing enough about Ops (and Unix in general) so that they don’t overthink things, and arrive at simple, scalable solutions.
I’ve dealt with a lot of idealistic bright-eyed, out-of-uni developers ready to “change the world with code” not having a single clue about the operating system(s) they develop for. I mean, it can’t possibly be their hulking Java monstrosity running via JetBrains causing their computer to crawl can it?
I hate over-engineered unmaintainable solutions bound to loads of extra dependencies across the vastness of GitHub and plug-in libraries to often achieve some mundane goal. The people who do these things are the same people that insist on fumbling with apps, home bridge kits, automation and location data to turn their lights off and on. Be wary of these people.
A huge gripe of mine in the tech space has been this nonstop reinventing/over-engineering of the wheel. The goal of computers were to free us, giving us time for more meaningful work and leisure. Yet here we are with the millionth JavaScript runtime guaranteed* to solve whatever problem didn’t really necessitate its creation in the first place because “we’re bored and want to feel important.”
Let’s conclude with a little pragmatism:
If you don’t want to think of it from a Zen perspective, be capitalist: you are writing software to put food on the table. You can minimize risk by using the well-proven tool set, or you can step into the land of the unknown. It may not get you invited to speak at conferences, but it will get the job done, and help keep your pager from going off at night.