Taper is an online literary zine that publishes tiny works of computational creativity. Specifically how tiny those works must be has varied a bit with some special issues, but the default instructions are that each submission must be created with no more than two kilobytes of code and data, and authors may not use external libraries or APIs.
Two kilobytes is 2048 typed characters (unless you type special characters or anything beyond the “extended ASCII” range, where a typed character uses two or more bytes for storage, but thinking of just thinking of a byte as a letter is more intuitive and generally true for writing in the English language). 2048 may sound like a lot of room to work with, but it runs out very quickly, especially if some of the tools you’re used to working with for making web stuff — webfonts, CSS frameworks, and JavaScript libraries — are not allowed. Any elements that you want in your work must be built from scratch using the tools inherent to the web browser, which can be challenging if your idea involves any interactivity, animation, or generativity.
I have completed three successful Taper submissions that were published in prior issues ( TriMoji , pent: house , and beauty and grace ), but this blog post is about my most recent attempt, which ended in failure. That is, I did get my idea to work in a way that makes me happy, but I just could not pare it down enough to meet the threshold. I tried every refactoring and minifying technique I could think of -- and I learned about several new techniques and online tools that attempt to automate the process of shrinking code -- I eventually had to give up. It was 3:00AM, and I kept falling asleep at my computer.
Maybe I could have kept going, but that night, the best I could do was still 469 bytes too many.
I reviewed it later, which was difficult owing to the extreme parsimony of the code, and I think I could maybe squeeze out another two or three dozen bytes -- which still wouldn't have been enough. ☹️
Since my work was acceptable for Taper, I want to share it here, and I also want to reflect on the relationship between coding and writing. The piece in question, "Menard-O-Tron" actually deals with that relationship in a thematic way, and I am interested in noticing and comparing what it was like to be in that moment writing the code for my project with the experience of writing text. But first, the project!
Menard-O-Tron
Jorge Luis Borges was an Argentinian writer whose metafictional concepts around language, time, and semiotics have influenced generations of people working with language, film, and digital literature. In one of Borges' more beguiling short stories, "Pierre Menard, Author of the Quixote," which was first published in 1939, the narrator eulogizes the nominative writer whose life work had been -- among other things -- to write Don Quixote. This is a counter-intuitive ambition because, of course, Miguel de Cervantes has already written Don Quixote. The fragments of the book Menard is able to complete before his death are letter-for-letter identical to Cervantes', but Borges's narrator praises the 20th-century work for its superior richness and subtlety. I take the irony here as an inquiry into the nature of what it means to write. After all, aren't all the words I'm writing here just exact copies of words that someone else has already written?
The theme for the forthcoming Taper issue is "Tools," so I wanted to explore Borges' idea with a tool that "writes" any file supplied by users, showing its "work" as it goes. You can try it out yourself, or just check out the snapshots below as it works its way through "The Jabberwocky".
The idea I wanted to explore here is the landscape of radically varying practices and skills which we refer to as "writing." I take this to be Borges' point as well, though I think he is also satirizing literary criticism.
For the Menard-O-Tron, I define "writing" as a heuristic or a way of making educated guesses, letter by letter, until a writing task is considered complete. Users can experience this with whichever file they choose to upload. ASCII text files probably work best, but it should work on anything computer-readable. To help visualize the heuristic, each guess is displayed briefly (about every 10ms, depending on your CPU), and the writer then moves on to the next character after each correct guess.
Users have two sets of options to create different experiences:
- Selecting the random heuristic creates a writer that knows all of the characters comprising the requested document, and it makes guesses randomly until finding the correct letter. Once that is found, it is added to the current string of already-written guesses.
- The alphabetic heuristic also starts with a list of all possible characters in the document, but it proceeds through that list in alphabetic order (that is, the ordering obtained by the
.sort()method). Characters occurring earlier in this sorted list will be guessed first and added to the string in progress. - And the frequency heuristic creates a list of characters sorted by priority. More frequently-used characters will end up at the top of that list so that they are guessed first. In all of my test documents, the most popular character has been the blank whitespace,
In order to make the differences between these heuristics more visible, I also created three methods for rendering the results of that writing onto the screen.
- The linear method, which I indicate with the → character, simply starts at the beginning of the uploaded document and writes its way through, character by character, as though it were transcribing it to a typewriter.
- The "⇉" method (or sweep) will spawn a writer for each line in the document and write them all simultaneously. The effect is like a ragged, left-to-write sweep that looks pretty cool, especially for poetry.
- And the "⇊" method, which I call rain, does something similar, but works vertically down the document, each column of text with its own writer. I like the "matrix rain" look of this rendering, but I think it also underscores the arbitrary, uncomprehending nature of these "heuristics."
Ultimately, I am pleased with how the resulting tool looks and works, and even though I could not adapt it to the required constraint of 2kb, I did enjoy the refactoring and compressing part of the process as well.
The Process
Writing is hard work. During my recent sabbatical, I did spend a lot of time writing, but I also spent a lot of time learning about the writing process and different tips for nurturing an active and effective writing life. Along the way I read several books about how to do this, and I deeply appreciated the weekly discussions with my writing group (meeting with a writing group is, by the way, one of the recommendations that nearly everyone endorsed, and I agree). Among those books about writing, I appreciated Paul Silvia's no-nonsense directives in How to Write a Lot :
From Helen Sword's Stylish Academic Writing , I especially appreciated "distant reading" of other style guides and her articulation of how to think through disciplinary writing conventions, including when to work with or against those in service of clarity.
William Germano's On Revision: The Only Writing that Counts taught me to be a better reader of my own writing, and several useful proofing and drafting techniques such as the "W" method and the "bullseye".
But the ideals I continue to strive for the most come from Joli Jensen's Write No Matter What . Jensen's approach starts by accepting the premise that the reasons we don't write are complex and valid, but there are ways we can move past them. This starts by being graceful to ourselves and recognizing the reality of our obstacles. Ultimately, Jensen's goal is that we make writing into "frequent, low-stress contact with a project that we enjoy," and after some frustrating setbacks on my manuscript, I think I'm getting there. Ironically, the workload of returning to full time teaching has helped me value my writing time even more as a welcome alternative to grading, responding to emails, and preparing for class.
For example, Jensen recommends starting by establishing a habit of 15-minutes per day and then building from there, and this recommendation arises from deprogramming one of the most common obstacles: the myth of an imaginary future self that has all their decks cleared and can engage in hours-long sessions of deep focus and creative productivity. I absolutely understand what she's saying, but it's a hard myth to let go of, especially when other ares of creativity do seem to lend themselves to that kind of flow state.
Working on this Menard-o-Tron was a challenging but deeply satisfying task. Opening my code editor and switching my brain away from linear composition mode into the problem-solving, brick-stacking, string-untangling, program writing mode felt physically different, like flexing different muscles. I sat on my couch worked at it for most of a long evening and into the early AM, only taking stretch brakes ever hour or two.
That I eventually gave up at around 3:00AM had more to do with recognizing that my self-imposed task was likely impossible than the fact that I kept nodding off.
What I'm wondering about now is whether it's possible to foster that same level of hyperfocus for manuscript writing and revision. I do think that my book-writing brain muscles are different than my class prep and email-writing brain muscles, but there are some big differences between writing code and writing scholarly prose. The argument that doing programming is a kind of writing per se is not always persuasive. Yes, code can be expressive, but even when it is, that doesn't mean it draws on the same resources as text.
It is also worth nothing, I was coding this project under a strict, non-negotiable deadline. So some amount of my motivation to keep working took hold within the anxiety about missing that deadline. It has been much harder to foster a similar anxiety for book-writing when I'm not under the same kind of deadline pressure (yet). I mean, sure, I know I need to get this done sooner rather than later, but I don't need it in order to bolster a tenure package. Publishing this book or failing to publish it: neither will (probably) not alter the course of my life in a major way. And besides, self-imposed deadlines rarely work for me because I am always able to forgive myself for missing them.
I have had some success in using music to curating my attention toward something like a hyperfocused flow state, including a few months working with Brain.fm as well as some similar concepts like "binaural beats." That works OK, but I've found that any kind of music can be interesting, and therefore any kind of music -- even ambient vibrations -- can be distracting.
What would be amazing would be if I can get that problem-solving, brick-stacking, string-untangling brain energy directed toward book writing, which could mean thinking about writing and composition in a more formulaic or least systematic way. A series of small problems whose solutions add up to solving a bigger problem.
I'm not sure how that would work, but this blog post has reminded me of something else Jensen recommends: a "vent file" for writing about the things that are frustrating you about your writing. This, too, counts as writing, and acts like a pressure valve to let out some of the tension that can block productivity. It doesn't matter that no one ever reads it (though if, somehow, anyone is still reading by this final paragraph, I am grateful for your time and attention), it just helps clear some of the clutter, which writing this post definitely has.
Word Count: 2048