gay robot noises

Comfy Software

A software aesthetic for hackers with depression.
date:
1584 words
VERTEX SPREAD

Modern software can be... a mess. Electron has made it easier to develop cross-platform applications, but at the cost of bloating everything by the footprint of an entire browser, and browsers themselves are getting more and more complicated. It feels like developers aren't really optimizing for resource usage; for a while, my main laptop was a Thinkpad T450s. In mid-2015, it was a fairly respectable laptop. In 2021, opening Twitter would make the fans spin up.

But there's still software out here that makes me feel happy to use, software that embodies an aesthetic that, for lack of a better word, I call cozy software. (Note: I originally called it 'cozy software', and I go back and forth depending on how much I like the /mf/ consonant cluster that day. The two terms are synonymous. My friend Luna referred to it as 'cuteware'.)

I'm not the person to come up with the term; I picked it up from someone or another on the Fediverse, and they might well have picked it up from someone else. But I've definitely been thinking about it a lot: what makes software a joy to use, both practically and ideologically?

The pillars of cozy software

In my opinion, the pillars of coziness (in no particular order) are:

This isn't a list I had in mind when I first thought about the concept; 'cozy software' is more of a family resemblance than something with rigorous definitions.

Customizability

I like making things feel like my own. This is part of why I switched away from macOS back to Linux a couple years ago: sure, things would usually 'just work' on macOS, but I didn't have the degree of control over it that I wanted. With Linux, I can pick my own window manager, my own desktop environment (or lack thereof), my own package management system, and so on. This machine feels like it's mine in a way that a Macbook never could.

Some people might say that, well, Ash, the time spent getting your window manager's background blur just right or optimizing your keybindings is time that you could've spent writing actual code. And that's certainly true. But: I actually like tweaking things like this. The point of all of this, all of the recreational stuff that I do, is to have fun. And then at work I can transfer my setup and have a nice environment that works just the way I like it, but without all the effort of having to get that stuff re-set-up again.

Extensive keyboard-focused controls

This doesn't mean that it has to be keyboard-only navigation or that the keyboard should be considered the primary way of interacting with the software. But you should be able to do most things with the keyboard that you could with the mouse. emacs and vim are the canonical examples of this, of course, but I'd say Blender actually falls in this category as well, from my limited time tooling around with it for a personal side project. It's very much designed to support a workflow where you use the mouse to pick out points and objects in the scene (which would probably be too painful to do with a keyboard) and then use the keyboard with your other hand to act on those objects. I'm not an artist, but from what I hear a lot of their tools work similarly; you set up shortcuts and keybinds so that you don't have to take your drawing hand off the mouse or the tablet pen.

Not-for-profit governance

In order for software to be comfy, the people who have the final say over what does and doesn't go into it shouldn't be beholden to a for-profit entity. This doesn't mean that the entity's development can't be led by a corporation; there are plenty of legal reasons to have your leadership be its own legal entity if you're a large project. But that entity itself should be actually a community focus, and not just a thin facade around one or two megacorporations that just dictate what happens (see: the emoji consortium, everything to do with the web).

I think of this as the 'no VS Code' clause: no matter how good VS Code is, I refuse to use it because it's fundamentally a Microsoft product and I want my text editor to actually be FOSS, dammit. It doesn't help that Pylance, their Python language implementation, is only licensed to work on official builds. Which ties in with the relationship between open source tooling and corporations... but that's a separate blog post.

Good documentation

This is an important part of good software in general, of course. But it's especially important for the cozy software aesthetic. Documentation should be available, and if the software is meant to run on a Unix machine, both --help and manpages should show you the help (no, GNU info doesn't count).

I shouldn't have to read the code to find out how something works; I shouldn't have to search "how do I X in Y". The program should be as self-contained as possible.

Funny enough, I think the class of software that succeeds at this the most is video games: they'll often have tutorials for things that someone who plays games as a hobby has done a hundred times before, just because every game is someone's first. If you have to look up how to do something online, that feels like a failure of the game.

Even in the days where games had actual manuals to go with them, Super Mario 64 tells you how to jump, punch, and move around. Of course, that's not universal; to pick another genre-defining example, Final Fantasy VI doesn't explain in the game itself how to move or what that number next to your character name in the battle screen is. Presumably the manual does, of course. But it does explain systems unique to the game like the Espers or Gau's Rage.

Of course, there are a lot of differences: tutorial sections are culturally accepted in games, but considered annoying in software. And a lot of software doesn't even have an interface at all; imagine trying to run find(1) for the first time only for it to open a curses-based tutorial! But it's something to think about.

Make the common things easy

The prototypical example here is find vs fd. Probably the single most common use case for these tools is finding something with a given string somewhere in the name underneath a given directory.

find has a very generic system where you can define a bunch of predicates and combine them arbitrarily, so you can say things like "find me files that were not modified in the past 5 months and are also more than 50 megabytes". The flip side of that is that it makes the common case annoyingly verbose: to find all files with foo in their names, you have to run find . -iname "*foo*" (the "i" standing for "ignoring case"). With fd, on the other hand, it's just fd foo ..

Similarly, it's also pretty common that you actually want to execute a command over all these files. Both tools let you do so, but the syntax is very different

find . -iname "*.pyc" -exec rm {} \;
fd . --extension pyc --exec rm

find requires you to explicitly terminate the command and specify where to splice in the argument; fd will infer both of those for you (but lets you specify them if the defaults don't work out). Of course, you can also use xargs in both cases, but if you're going to supply a way to do something then you should make it nice to use.

Finally, fd has various other niceties like respecting .gitignore and color output.

I'm not using this to pick on find specifically, but it's a good illustration of how one of these was written a few years ago and the other was written in 1990.

A cute name

This is the most vague and 'vibe-based' of them all, and is the least important. But I like it when software has a name that has 'kawaii' in the acronym or is named after a fictional character or has a name that's just plain fun. Obsidian also falls in this category; even though I can't think of how the name relates to note-taking, it's just a nice name for software.

Towards a cozier future

Obviously, not all software needs to fit into this. Most software written professionally will fail the 'non-corporate governance' test, and it's harder to get that 'cute' feeling going for something that isn't something you're working on because you're getting paid. But I've been giving the internal tools I've been building at work some of this character: naming them after video game characters, writing long "if you got this error, you probably tried to do X. That doesn't work because Y. Do Z instead" messages, and so on. And if that means you name your firewall management service yuna, so be it. Having a little fun is important.

// α-5/h