What do we mean when we say ‘code is expressive,’ anyway?

code
Author

Alan Schussman

Published

January 4, 2024

Abstract
No, seriously

I’ve been thinking the past couple of days about what we mean when we say that code is “expressive.” I’ve said it myself, but never needed to unpack just what I meant until I found myself using the phrase as part of a motivating idea behind a project I’m looking to gather support for. I should probably know what I mean; somebody might ask.

“Code is expressive.”

Look, there’s a ton of search results for what this means and they’re probably mostly alright. (I committed to not doing my homework before writing this, so I’ve only grazed some titles, and a lot of it sounded pretty computer sciencey) Expressive code is readable, maybe it “makes APIs discoverable” because it helps one to intuit how elements of a system work, maybe it’s really elegant — whatever that means. I see there are also debates about what languages are “most expressive,” but, y’all, I can’t stay up all night on Thursdays getting into that on a listserv, anymore.

I think this particular use of expressive really mostly is used to mean readily interpretable or understandable, with some room around the edges to mean some amount of a sort of ineffable chefs kiss emoji; that makes a lot of sense to me, but it also puts a lot of the value decision, the assessment, in the hands of the view-er, not the do-er. I think that leaves out the really important element that doing something expressive is itself valuable. It feels really good to convince a computer to do something I want it to do just by typing at it, and it feels astonishingly good, every time, to do it in a way that’s clever, parsimonious, innovative, or even elegant. (I am on record as having never quite gotten over the magical feeling of seeing markup language get turned into typeset PDFs or web pages.)

So if expressivity can be owned just as much by the creator, I think we get to this really important and valuable position, that of recognizing it as a motivator for doing the work. That’s the part that I think is so useful to be expansive about: working in code is is itself expressive, and not just in the stuff you’re banging out on the keyboard (which, as stipulated, is also good).

“Working in code is expressive” means that my environment also says something. Jim Gardner put this so aptly in a thread about “what does pythonic mean”: Basically, it’s about vibes, and that’s the phrase that got me to take out the laptop when it was really bedtime to start writing this all down. Right now, I have this Quarto file open in three totally different editors.

Each one feels a little different, and working in each one asks me to perform a little differently. Just like choosing which perfectly good jacket to wear out in the storm (jacket people, you know what I’m talking about, here, when I say that nothing is quite like that first day of autumn when the weather is finally just right for that one ratty orange fleece that’s been everywhere, and isn’t right for every day, but it’s right for that day), there’s not a bad choice here — look how they happily coexist! Sometimes a seamless IDE fits how I want to work; sometimes I want the vibe that comes with doing everything in nvim and terminal windows. (Oh, I could make that terminal window a little bit transparent and turn on ligatures, that’s be pretty cool.) Sometimes I think it would be really great to swap between code and an org-mode document as I work, right in the same application.

Okay, why care about this? I care about it as a person who likes — loves — to make things, and I lead some fantastic people who also like to make things. Editors are just one example of: It’s fun to learn about people by seeing how they make things! When was the last time you got on a screen share with a group of people doing work in code of some kind, and somewhere along the way somebody on the call didn’t ask “hey, what color scheme is that?” or (zeroing in some tiny on-screen detail that has nothing to do with the work at hand) “what’s that icon do?” or “whoa, why does that CSV file look like a rainbow?” ? If your answer is “never,” or “rarely,” you might work in a pretty good place! Each of those is an opportunity to learn something you didn’t know, and maybe a chance to learn something about your colleague, too, because our tools give us just a little bit of room to be expressive.

Believing that kind of interaction is a part of learning, collegiality, and doing innovative things by accumulating ways of working from others, I think we should encourage expressivity. There’s a cynical, superficial read of this that I want to avoid by emphasizing that this isn’t about aesthetics and dark mode (sometimes just very very dark gray), and it’s not only about ways of “being seen” because much of our work still happens individually. Let’s be generous by being explicit that the way we work is as valuable to each of us, as individuals, as the stuff we make to earn our paycheck. It matters to me that I can work in tools that are expressive, and I think it matters to the people on my team, so I want to make sure that it matters to my organization, too.