Terminally Enthused
I get into cycles. I’ll discover a great new productivity tool, then abandon it, then rediscover it months later and try to integrate it with everything, wash, rinse, repeat. This is maybe to be expected, given my clinically short attention span and fascination with the shiny and new. In order for an interest to stick, I’ve found it needs to be something I come back to again and again for different reasons. That’s why today I’m writing about the terminal.
Plenty of people use and abuse terminal commands in day to day life. I was dragged kicking and screaming into the standard mac terminal way back when I was attempting computer science classes with a vague idea of getting hired as a junior developer somewhere (didn’t pan out, clearly, or I’d be one of the self-advertising bunch I complained about in my last post). Since then, I’ve installed Homebrew, swapped from bash to zsh with the rest of the mac world, customized my zshrc all to hell, I’m just getting started with tmux and I just today came across a nice little in-terminal music player called cmus.
It was here, as I was looking into getting rid of my mail client and installing NeoMutt, that I had to pause. Why exactly is this so fascinating? I don’t have a particular love for text over GUI, and empathize with people who would rather never touch the console commands if they don’t have to. And that’s the thing: in a modern GUI app ecosystem, you should never have to outside of very specific use cases. But there’s a reason I think people who learn to use the terminal tend to dive in and never emerge. And as much as people hype the incredible efficiency of keystroke-only systems, I don’t think efficiency has anything to do with it other than bare justification. The truth is, the terminal offers control, or at the very least the illusion of control, as opposed to being presented with a short list of buttons to push.
My second job, the one I’m still partly employed at during the COVID crisis, is tech services. I actually do find some joy in my work - if someone walks in with an apparently inoperable computer, I get to be the hero more often than not. I get a lot of older customers, though, and I find they tend to become overwhelmed easily by options and menus. Partly this is the fault of bad user interface designs and the rollout of poorly explained, mostly unnecessary feature updates, but I think there’s an underlying psychological effect caused, ironically, by lack of choice - the options are the way they are, and if they don’t do what they seem to do, then there’s no recourse. By no recourse I don’t mean it’s an unsolvable problem, but that most methods that occur to the average person don’t work. Customer service lines are staffed by overworked, undertrained, underpaid people, often thousands of miles away, working off scripts and unable to use what training they do have, if they even had the desire to do so, and usually require the customer to pay up front. Help menus are often poorly documented and reliant on internet access, or behind baroque support forums. Nowhere in this process can the user find an outlet for their fundamental frustration - there’s nothing wrong with them, there’s something wrong with the computer!
In what senses is this true, from behind the counter? Obviously, the computer’s only doing what it’s told - it’s an intermediary between a faceless corporation and a person with a practical problem and very few tools for solving it. But in a sense they’re right. The problem is with the way the computer system overpromises and underdelivers on simplicity. The problem is we’ve shielded people from how their devices work so effectively that they no longer feel either obligated or, indeed, empowered to develop a relationship with their devices or find out how to maintain them. It’s the same reason I’ve barely looked under the hood of my car except to change the oil and refill the washer fluid - it’s all I know how to do, and god help me if something else breaks. Likewise, it’s impossible to ask anyone who would know, anyone who helped make it. This is a direct consequence of the ideology baked into modern software - in an attempt to make the isolated individual king of their software experience, we’ve locked them out from understanding, from community, and therefore from any meaningful choice.
This is where the terminal comes into play. Modern terminal tools, even ones that have viable GUI alternatives, achieve success because they are able to ask the user - “Now really and specifically, what do you want, and can we help you get there?” Not only that, but there are most often well-documented answers to whether such a thing is possible, and failing that, a community of hobbyists ready to answer even the most obtuse questions. This isn’t a perfect system - it allows for genuine conflict between people, which the system of tech support lines is designed to avoid and defuse. But in allowing direct conflict, in allowing a smartass developer to mouth off to a user about how they didn’t read the manual, projects avoid the much larger problem of opaque, uncaring, unworkable systems designed to a manager’s spec, designed to offload its failures onto the userbase in a way that lets the company escape responsibility. Partnership between the end user and developer may ultimately be a pipe dream, but it’s got a sense of possibility to it. And there’s no better way to get a taste of that possibility than by using a bunch of extensible terminal tools with options you’ll never need - because chances are, the people who developed the product did so because they wanted something to use for themselves, so they actually care about making the end result work, and work well. And even if it’s a crap, they care enough to explain how they did it, so someone else can take it and improve it.
I may be too deep in this to come out with anything less than an incomprehensible, irreplaceable custom UI and a wild-eyed expression, but I no longer care. I’m in it now, and I’m liking what I see.
Long live the terminal.