On programming and poetry (not Python’s tool)

Some thoughts on how programming’s unlikely relations to poetry, and some implications of those relations

I don’t have much time recently to work on articles about programming (especially considering my typical article length); but I have some previously written content to share. This article was drafted as a Twitter thread on my 39th birthday: a day when I published my new site, and announced “I’ll be writing more here soon!” It was Feb 14, 2022, ten days before the full-scale Russian invasion started. Two and a half years later, I finally go to making it into a standalone text with clearer arguments, some links and conclusions. Anyway.

You don’t see poetry (as in writing and reading poems, not the Python tool) mentioned besides programming frequently. And when it is, it is usually in one of two ways:

• to contrast “soulful” humanitarian activity to the “boring” engineering one or
• to use “poetry” as an informal synonym for “beauty,” to say that some code “reads like poetry” is to say it is nice, or expressive, or in some other way pleases the author of the statement.

But I believe there could be deeper insights in looking at them together. Here are some assorted thoughts on it.

Am I qualified to write about the topic?

Judge yourself.

From the software development side: I am a software architect, writing code for 25+ years, a Ruby programming language committer, author of some open source libraries, many texts, and some documentation projects; in former days, I did a lot of Ruby mentoring, including teaching people who had no prior knowledge about Ruby/programming whatsoever.

From the poetry/writing side: I have been writing prose and poetry for as long as I can remember myself; my first novel just had been published recently.

I considered myself primarily a poet for at least a decade between my mid-20s and mid-30s. I didn’t achieve much more than occasional magazine publication or festival participation (almost got my first book published, but then the publisher went bankrupt). Nevertheless, I had enough community validation to at least believe I understand some things about it (even if not excel myself).

I stopped writing poetry a few years ago (and switched to prose, that’s a different story). Some of my recent texts can be here (mostly in Russian, which I don’t use anymore, obviously).

I also organized a notable online poetry festival in 2017, before it was cool! (The site is down currently, and the remains of the festival are scrubbed from the internet for reasons too complicated to explain. However, I was exposed to a large number of authors from all over Western Europe who wrote in several Slavic languages—Serbian, Croatian, Bulgarian, Slovak, Polish, etc.—which was an educative experience in itself.)

I still read a lot of poetry and ON poetry and try to understand the broad context; this year, I started the 7uapoems project, dedicated to the translation of modern Ukrainian poetry written by those who are currently in the army.

With that being said, I am not really strong on literary theory, so all attempts to define things in the text below are my own. For those well-versed (pun intended) in theoretical matters, it would probably be irritating or laughable.

I don’t also try to go into precise theoretical terms on the software development point of view. This, I could’ve done, but my way of thinking and talking about things is usually “in layman’s terms,” for better or worse.

Why do we write and read literature

A loose attempt to define some things

Why do we write and read literature, any literature?

Mostly to share an experience. An experience of going somewhere, living through some events, feeling some emotions, understanding some things. The experience we probably can’t access directly. (Yes, there is also room for a variety of literature, which just helps to relive familiar experiences, but let’s not complicate it further.)

In the scope of this definition, poetry, in a nutshell, is a more efficient way of sharing an experience that is hard to express rationally. It relies on some “leap” of understanding, where a carefully crafted phrase is as efficient as five dense pages of explanations. (“Oversimplification” is my middle name!)

That has actually nothing to do with “beauty,” which is just one of the poetic tools that can be used, rejected, or subverted; in bad poetry, “beautifully crafted” lines can mask the triviality of the meanings conveyed/experiences shared.

While I stopped writing poetry, I still believe that the “poetic” way of passing the experience is the most efficient in many cases. And, to the best of my perception, I have never stopped doing poetic work while writing prose. There are “prosaic” writing tools: structuring the plot, taking care of worldbuilding, and inventing compelling motivations for characters, and there are “poetic” tools: choosing the tone, rhythmand imagery that would immerse the reader—and both kinds of tools are likely to be present in any forms of writing, in different amounts.

Conversely, if you don’t like to read poetry (or even don’t understand why one would do it), it might mean you might not have met the kind that communicates to you and your experience, or your temperament doesn’t require this particular form of writing. This is just a personal characteristic, and it doesn’t mean that you are never exposed to poetic tools of writing in other texts. And hopefully, this also doesn’t mean that there is nothing you can take from my comparisons.

A fragment from Artur Dron’s poem, “Izyum communion”. The translation is mine.

How is programming related?

In the casual “engineering vs art” framework of thought, programming seems to oppose poetry. And yet, in former years, every time I shyly mentioned at a programming conference “…and also a poet”, there were people around—frequently, distinguished engineers—to say “me too!”

A quote via Alex Bilzerian, shown to me by my friend Dima Ermilov

I am thinking and writing a lot about perceiving code as text and intuitions/approaches/expectations it brings. One of the first articles on this blog (nine years ago, huh) was about Ruby’s suitability for “writer” kind of programmers; my recent EuRuKo talk also had “writing stories in code” as one of the key themes.

Taking the definition of writing from earlier, we can say that writing code is sharing the experience of understanding the requirements/implementation.

Looking from this point, we can clearly see room for poetic work here: it is frequently useful—at least with some mindsets—to start solving the task with the several “phrases” that make the leap over the whole implementation domain.

The topic is quite divisive: to the extent when any attempt to compress meaning with modern language features is frowned upon—especially sad to observe in the Ruby community, where the discrepancy between language’s intent and community practices seems to only grow with time.

The “poetic” approaches get ghettoized in the languages more friendly to leaps of understanding but less readable as everyday prose, like Perl and APL. (Aside note: the original thread was partially triggered by the first episode of The Array Cast podcast, explicitly mentioning poetry in regards to APL and related languages. But even there, if I remember correctly, it was mentioned rather as a generic synonym for “something beautiful/pleasant to read,” though the users of terse languages might be, indeed, closer to agreeing with the value of “pass the experience in an intuitive way via carefully crafted line of text.”)

The thing is, I believe that poetic work is a valid and useful tool.

Sometimes, “poetic” code is useful in the drafting stage, and then it is expanded—fully or partially—into a more verbose “prose,” all the modules and services and concerns.

Sometimes, the succinct, “intuitive” expression is the best, and it is acknowledged as such by most of the readers—the same way some lines of poems become proverbs. We frequently call these “idioms” in coding (I have my concerns with this term, but that’s for another time).

It might be an uncommon opinion, but the amount of code solving the same task might differ strikingly (talk orders of magnitude) if the “stop, think, write one verse” approach (instead of “write 20 pages of your usual”) matches the task.

And maintaining five lines of code—even one that leans on intuitions—is, in any case, cheaper than maintaining 20 files of it. A big part of the industry at some point stopped believing that, so the “don’t write smart code” argument is usually argued as “2 lines of ‘simple’ code against 1 line of ‘smart’.”

So what?

Whether you sold on my comparison or not, you might wonder about its utility. Like, OK, programming, or some kinds of it, might or might not bear some resemblance to “poetic work,” but where does it lead us?

The thing is, I would like to see more people treating code on the level of phrases and “paragraphs” (methods or groups of statements) with the mindset of how the literature is treated. And I mean it not as just another way of saying, “let’s write bEAuTifuL code and be free as butterflies!”

I am talking about the kind of perspective from which we can analyze, discuss (and maybe teach ourselves) to think in terms of the effect on the potential reader (both human and compiler/interpreter) in terms of “how meanings of expression, in this case, convey the idea behind the code; whether it could be expressed in a different way to emphasize a different aspect.” It is a conversation that is less rigid than autoformatting and style guides and more nuanced than abstract “readability” or “smart/simple code.”

But time and again, when I have this conversation with people (colleagues or just participants of online discussions), it is a two-stop track: first, “it is all subjective, and just depends on who likes what,” and when presented with less-subjective analysis/explanation about how the text/code might be perceived, the second and final stop is “maybe, but I don’t understand why you pay so much attention to this, it is all nitpicking.”

But I still believe this is a conversation worth having. I would like to see, for example, some “literary” criticism of new releases of a popular library, along the lines of “this is a stylistic approach this author usually takes, which works this way, and is perfect for tasks like A, yet in situation B it leads to those possible misunderstandings…”—but we can’t have that, without being labeled as “subjective” or “nitpicking,” because “well, it works, what else do you need?”

We also need to recognize and cherish wild experimenting with form and style, the “poet’s poet” notion: code that, as it is, you’ll hardly use in production and in a team, but which helps to investigate the possibilities of the expressive power of your language, and master them to use appropriately.

The end goal here, again, is not some abstract “beauty” or “engineering excellence” but pragmatic values we all share: maintainability, openness to change—things that are affected with clarity of understanding, which, in turn, depends on how the things are expressed.

That’s why I return to the topic of code and text constantly and from different angles. Not for the last time, probably!

See also: “Do programmers dream of electric poems?”, an article by Facundo Olano which investigates similar topics with somewhat different argumentation.

---

Thank you for reading. Please support Ukraine with your donations and lobbying for military and humanitarian help. Here, you’ll find a comprehensive information source and many links to state and private funds accepting donations.

If you don’t have time to process it all, donating to Come Back Alive foundation is always a good choice.