Do-nothing software development

I started a professional sabbatical in January. For the first few months, I continued to write code, but starting in March, I've almost completely stopped. The distance from actively building software has reinforced my sense that a lot of software work is unnecessary and the tech industry could benefit enormously from a spirit of doing nothing. This perspective is, of course, completely at odds with the Bay Area attitude of "agency", of fast-paced, ultra-productive developers working incredible hours bringing forth the future, especially in the era of AI.

All sorts of "nothing" already happens in the tech economy. Meta invested 80 billion dollars in its metaverse to create nothing. The cryptocurrency industry has as its ground massive GPU farms that do pointless math equations. In the ZIRP era, investors like Masayoshi Son threw billions of dollars at companies like a now-bankrupt WeWork to spin their wheels and lose money. It turns out there's a lot of business in nothing.

Everyone involved in these decisions, at the same time, celebrates "hard work" and detests sloth. In the tech economy, one can never truly, honestly be "doing nothing" – resting, contemplating, exploring, and so on. One must be actively doing and justifying pointless endeavors, often with extraordinary intensity and personal investment.

In How to do Nothing, Jenny Odell describes a project by performance artist Pilvi Takala called The Trainee, where the artist spent a month as an intern at Deloitte office hanging out and literally doing nothing. Her presence was deeply unsettling to her colleagues, and threatened the atmosphere of the office. In an office environment, everyone must be doing something at all times, and anyone who does not appear sufficiently busy is treated with deep suspicion.

This is despite the fact that a lot of "activity" at, for example, tech companies, is at best pointless, and at worst actively destructive towards the company's goals. Elizabeth Ayer writes in her essay Enshittification as Overproduction in Software about the ubiquitous "elephant curve": after a period of growth, a mature software company has nothing to do, and so undermines its own product in pursuit of growth. When an entire company is structured around "exponential" growth and that growth stalls, it is totally unequipped to shift towards what would be a more effective strategy of maintenance, preservation, platform stability, and cutting rather than adding features.

Internal company dynamics at tech companies can also produce pointless work. "Promotion-driven development" leads to engineers building impressively over-complex systems to justify a bigger title. "Empire building" is a similar phenomenon at a higher level: mid-level managers justifying their inflated staff by a list of "accomplishments." Oftentimes, these so-called accomplishments cause more problems than they solve, which itself can be a thing to celebrate: because it means more work to add to a future accomplishments list! The idea that a project may have been a mistake or a waste of time is completely inadmissible: rather, the work's pointlessness is justified simply by nature of it having been done.

On the other hand, despite their obsession with pointless work, tech companies neglect essential work that actually, openly looks like "nothing": quiet contemplation, consideration, and reflection, or even just not doing a project. Simply figuring out a reason why something shouldn't be done can save a company thousands of person-hours, but is not celebrated, because no end of quarter list includes things not done. Meanwhile, "maintenance work" essential to platform stability and the durability of a software system is considered "nothing" and largely overlooked.

Sometimes, the best way of doing software work is, in fact, rest, non-action, even sloth. Rich Hickey describes "Hammock Driven Development" — stepping away from a problem, "sleeping on it" and letting one's "background mind" figure it out. For many tech companies, this kind of behavior (say, taking a mid-day walk or having an aimless chat with coworkers) would be treated with hostility, "wasting time."

The issue of over-production is not isolated to large tech companies. Programmers, often, like to code, but this often means that they solve false problems out of interest and passion. They want to make "the perfect" note-taking system, static site generator, laptop configuration, or other personal project that solves their niche needs. There is nothing particularly wrong with this kind of tinkering (I've indulged in it myself at times), but it is easy to become deceived by the impression that because you spent a long time on something or enjoy doing it, it is a worthwhile pursuit. Work often justifies and begets work.

mike_hock on Hacker News criticizes ultra-minimalist suckless software, which has a different ethos:

Suckless, on the other hand, is impractical esthetic minimalism that removes "bloat" by removing the program.

Ironically, this seems to grasp exactly what is worth celebrating about suckless's philosophy. There is a lot of software that simply does not need to exist, that is justified simply by nature of problems that it generates itself. I use some suckless software, for example, st (their terminal emulator), and I've never sought a feature that it doesn't have. And yet, there are endless projects where developers are writing hundreds of thousands of lines of code trying to create "the perfect" terminal emulator, complete with a bunch of features that I have never even considered that I would need. st doesn't really work on Mac OS, where instead I have used iTerm, and am subjected weekly to a list of "new features," none of which seem to improve the program itself. I don't object to hobby projects, but these are not exactly creative works, rather, they purport to be useful. I question how much software there is that we wouldn't be better off without.

Using ultra-minimalist software, I often find myself wondering what more "complex" programs are actually meant to be doing: it seems like they are primarily solving self-created problems. I certainly had the same experience in my professional life, encountering systems whose complexity has an articulable self-justification, but whose actual value is never really questioned.

Some problem domains are basically solved, and some programs are "good enough". Take, for example: the field of writing, where there exists sophisticated (paid) software tools like Scrivener with intense devotees. On the other hand, George R.R. Martin wrote Game of Thrones on a 1980s version of Wordstar. It's not unheard of for writers to still primarily write longhand. I'm writing this post as HTML text in mostly unmodified vim.

Using a complex technology may give one the impression that they are more productive and doing better, but I am highly suspicious of impressions. For example, I even tried spending some time coding without syntax highlighting, something most people would consider absurdly austere (except for Rob Pike) and no honest assessment I make can really tell me whether it impacted my productivity at all – though one advantage is that it made me less reliant on syntax highlighting, and more comfortable in environments where it was absent.

The radical idea of suckless is that we should demand less, not more, from software – that we should limit what we should expect our software to do in order to spend less time building and maintaining it. This seems closely related to the concept of Permacomputing, that software should be considered holistically through its entire lifecycle of production and maintenance, not just by its feature set as a final product.

Hidden within this comment's criticism is a wider potential minimalism, which is that there are a lot of programs that could be removed, things we don't need to or shouldn't be building. On every level, there are cases in which the preferable choice is simply to be not making things, and the best software eliminates, rather than creates, the need for more software. The embedded system of an old clock radio eliminates the need for a far more complex software iPhone alarm.

Perhaps, freed from the need to create software to solve false problems, our efforts could be spent elsewhere – towards "pointless" efforts of a different kind: projects whose goals are more undirected, loosely defined: creative expression, exploration, intellectual curiosity, preservation, and maintenance. Perhaps software can, in this way, more resemble the arts, whose "purpose" is more openly ambiguous. And perhaps we could, broadly speaking, spend less time on software entirely, and more time broadly on undirected leisure in all its forms, more time appreciating other kinds of creative expression, more time paying attention, being receptive and open to the world, to others. It is through this ethos, rather that than of endless "productive" hustle, that we can do our best, most transformative work.