By the time I finished writing this blog post, I had come to a realization that wasn’t even on my mind at the start: The active function (in as utilitarian a sense as possible) of an object is just as important in creative production as its affective and aesthetic potential.
[This might make more sense if we have a flashback sequence.]
I created a piece of Interactive Fiction through Twine 2 this past weekend as part of a potential skills workshop and (writing) instructor lesson plan. As I experimented with the various story formats – which determine the type of code and syntax you use – I found myself attempting to combine the incompatible, and calling on obsolete macros. I wanted the best of both worlds: the pre-set commands in the Harlowe format, and the creative flexibility of Snowman. I wanted the option to rely on the existing, built-in commands of TwineScript (from the Harlowe format), and the option to write my own, tailored functions and objects whenever – wherever – necessary. And yet, this was ultimately more time-consuming than consistently relying on a specific script (i.e. JavaScript). In what would become a fruitless venture, I spent 6 hours alone trying to connect a user-defined JS function to a TS command.
It. Was. Miserable.
It wasn’t necessarily the fact that the languages were difficult to meld, or that I was struggling. It was that changes were and are unforgiving in coding. Changes typically come in the form of patches (updates), which improve/fix/regress/break a program and can often directly impact the code and functionality regardless of intent. For instance, some of the established macros I tried from a Twine 1 guide no longer applied to Harlowe (in Twine 2). I became increasingly frustrated. I was frustrated by the lack of anything shareable on my screen. I was frustrated by the presence of a distinct vision I could not implement. I was frustrated that this act of failed creation was not something I wanted to lay claim to. In short, I was frustrated by my dissatisfied ego.
What I forgot, and what should’ve been more important of a concern, was this: these changes prevented me from making my design useful, and therefore, meaningful. Because in code, use is meaning.
[End flashback.]
As rhetoricians, historians, literary scholars, linguists, etc. we are well aware that languages change. Words disappear. Words gain new functions. However, creative production in literature (and other arts such as film, and music, and sculpture) can and does utilize elements that are obsolete and/or unconventional. Paints and clay, harmonic progressions and notes, cameras and lights – even if these components transform over time, the transformations do not erase a piece of work from consideration because we, as a society, prioritize the composition’s emotional and aesthetic qualities (and the creator’s by proxy). Whether or not the audience understands the work, whether or not the work is accessible (or “good”), is a separate issue.
With code, though, placing the fundamental creative building blocks on a page is not enough. The blocks remain inert, incomplete. And, unless we treat the code-text itself as another form of static art by analogizing it (and thus losing an essential part of it), we must acknowledge that the societal value of code comes from its motion, its active function after the building blocks have been successfully merged into something greater. [Kind of like the Megazords from Power Rangers.] So much of how we as consumers see code is delivered through an interface that has already transformed code into a whole Thing – a running program distinct from its creator. On the other hand, when the lines of code don’t harmonize, when they cannot be mediated through an interface and an audience cannot appreciate the results, what do the coders see? Maybe a work-in-progress, a palette containing strings of text that have yet to make it to canvas. Unbound. Unorganized. And when the lines of code do harmonize? Well, I see a program that could, at any moment, be rendered useless/un-executable by a patch.
It is this transience that helps coding become more than a derivation of the self. My pride, my investment, my sense of accomplishment are rendered irrelevant when the task at hand is ultimately about function. When I code, I am attempting to create an interactive experience that goes beyond an aesthetics – and perhaps an affect – inevitably influenced by my subjectivity. That isn’t to say that all of these elements aren’t in digital creation; they are. It’s simply that coding is an art that subordinates and diffuses the creator’s (frequently creators’) involvement in favor of prioritizing what is given to the user: the function of visual effects. The function of dialogue. The function of mechanics. All of it, I argue, is framed by function.
I am reminded of sandpainting, for which the Navajo are famous. It is a temporary work created for a spiritual, healing purpose, destroyed once that purpose is completed. The act requires a sensitivity to the larger picture, literally and figuratively. Sandpainting is made beautiful and meaningful by the function it serves for another, and its ephemerality.
If code, too, is defined by its practical use – that’s not a bad thing.
Featured Image: http://www.csfieldguide.org.nz/en/chapters/software-engineering.html
