CLI status: cultural factors behind CLI usage
As discussed in my separate article on the tradeoffs between Web UIs and CLIs, there are a multitude of concrete reasons for software professionals to favor CLIs (command-line interfaces) over GUIs (graphical user interfaces), depending on the task at hand. While these reasons are often enough on their own to drive usage of the CLI, I believe there are also a number of interesting cultural factors at play behind the preference for CLIs in software communities. The following is my personal account of some of these factors, as I’ve understood and experienced them. As mindful software professionals & UX (user experience) designers pursuing a rational approach to our decisions, it may be interesting to examine some of these subtle factors, and how they may impact both our own preferences and the preferences of our users.
The Anti-Aesthetic Aesthetic
To be a developer is to engage in the fundamental essence of problems and the systems around them, stripping problems of their superficial trappings to engage directly with their essential core. In this world, all that matters is the mind and its ability to conquer problems. The rest is a distraction.
This often useful perspective for working with computers (or indeed problems in general) can also manifest as a sort of anti-aesthetic aesthetic that eschews the superficial in all things. It extends beyond the world of computers to other parts of life, from wearing free conference t-shirts for products you don’t care about, to allowing facial hair to grow naturally without the overhead of laborious trimming. All the better to focus your time and energy on what matters.
The CLI speaks to this anti-aesthetic by almost entirely eliminating the presentation layer, instead hooking you directly into the raw data. Why should a developer fill his network connection with those unnecessary bits if he can tap into the fundamental essence of the system?
Complexity masochism
Engaging with difficult, unforgiving problems is a rite of passage for developers that goes back to the earliest days of computer hobbyists. Why buy a pre-built computer when you can assemble one by hand? Why do a default install of an operating system when you can install Gentoo Linux, compiling everything from scratch with hundreds of different compiler flags for the absolute optimal result? Why use the default OS for your phone when you can jailbreak it and install your own system that you have total control over? Sometimes this approach is in service of developing a better understanding of a system or is motivated by a legitimate need for more control, but when undertaken for the sake of the complexity or difficulty itself, or when used in the service of ‘gatekeeping’ against less experienced users, it can be counterproductive. For UX designers, the cultural appeal of complexity in a user base can be especially vexing, since a core value UX brings to the table is to make things easier.
The ‘Matrix’ effect
The ‘Matrix’ effect exists at the intersection of the anti-aesthetic aesthetic and complexity masochism, where the impenetrable complexity of a CLI’s data leaves outsiders no choice but to stand in awe of the data’s alluring aesthetic.
Your grandmother can use web UIs, but only a true initiate can decipher the cryptic ‘code’ of the CLI.
Pop culture is full of examples of this ‘hacksploitation’ genre trope, most notably “The Matrix”, but also shows such as “Mr. Robot”, cult-classic movies such as “Hackers”, “CSI”, etc. By showing that we can decode a strange and obscure interface, and that we can consume and make sense of vast quantities of raw data, we project our talent to our peers and cultural outsiders alike.
(See https://hackertyper.net/ to experience some of the magic and the mystery yourself).
‘RTFM’ culture
An empathy gap often exists when it comes to appreciating the difference between making a certain capability of a tool technically possible and theoretically discoverable vs. making a capability easy to use and easily discoverable. The trope of an open-source project maintainer telling a newbie to ‘RTFM’ (read the f*ing manual) belies this gap. Typically, on the CLI anything is ‘possible’, but the process of discovering the right thing to do without already fully grokking the system is too often left as an exercise for the reader.
One subtle reason an empathy gap can occur between system creators/maintainers and users is that in the process of developing a tool, one often becomes one of the world’s most expert users of that tool, inadvertently making the tool’s authors uniquely unsuited to appreciating the perspective of the beginner. (See the book ‘The Inmates are Running the Asylum’ for more on this.)
(Note that designers can be as vulnerable to this issue as developers. Good designers and developers know this, and will intentionally course-correct by seeking outside feedback and testing their work with users that don’t yet understand the system.)
The ‘RTFM’ perspective is thankfully not as common as it once was, with tools such as the Ruby programming language having ushered in a conversation on the value of cognitive ergonomics over system purity and efficiency. But the cultural residue of this perspective is still very much visible in the present day, for example in the sorry state of documentation on many open source projects, even when the underlying technology itself may be excellent.
Bridging the gap between the possible and the easy is perhaps less glorious than making the impossible possible. But for practical purposes, I would argue that ease of use is equally important. Making the impossible possible typically benefits the users that have already pushed a tool to its absolute limits, but making the possible easy benefits all users, whether they’ve run into the wall of a tool’s full capabilities or not. To create a sustainable ecosystem around your product, both new users and power users need to be satisfied.
Conclusion
I hope that none of this is interpreted as a denouncement of developer culture. As a developer myself, I have a love for much of this culture, and enjoy bringing this perspective into my craft as a UX designer.
One of the cultural values mentioned above that resonates with me strongly is the desire to eschew the superficial in favor of the fundamental. Following this value to its conclusion entails a certain amount of self reflection; how much are we driven by fundamental truths vs. cultural biases? Too often, biases masquerade under the guise of facts, which only serves to make conversations more ambiguous and difficult. In the case of the benefits of the CLI vs. GUIs, the temptation to uniformly discount GUIs as beneath real software professionals may overlook more nuanced opportunities to improve a tool’s overall experience by leveraging GUIs in the right way, at the right time. [See this article for more on this topic.]
That being said, there’s nothing wrong with choosing to exclusively use a CLI tool in part because it is more fun for you, or because it fits with your values. But in our roles as the creators of products that have the potential to touch millions of users, there is a greater responsibility to consider both the cultural and more concrete influences behind our decisions, in order to ensure the best possible overall experience for your users.
Micah Linnemeier is a UX designer and developer at IBM Cloud based in Austin, Texas. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
