Coding – or perhaps more traditionally known as ‘programming’ – is a process where one writes instructions for a machine to operate based on possibly changing conditions. It is a series, and a network of logical operations derived from conceptual rules being checked, compared against varying factors and then acted upon – an algorithm, collectively.
By virtue of its intent, and depending on who you ask, coding sometimes takes on a bad reputation: of being technical, procedural, devoid of the mess that humanity sometimes enjoys in our encounters in our world. Wikipedia describes an algorithm as “an unambiguous specification of how to solve a class of problems”. How precise and unforgiving! I wonder how living life with such clinical clarity feels like. But yet, even the most technical, constrained mechanisms that we know of still spark a sense of wonder – the tiny movements of an automatic watch, for example. Or the satisfaction of watching videos of pasta making machines on Reddit.
From a practical and utilitarian perspective, there seems ostensibly nothing to be excited about when writing code. To the unfamiliar, it is a series of keywords and cryptic symbols. And to those who depend on writing code for a living, it is an efficient language that bridges the divide between machine and human. It is, above all things, a tool; an extension of the thoughts and processes crystallised by the code writer, to deliver certain intended responses or patterns of responses, even if some of these responses have entropy intentionally embedded within. It is a canvas from which an artist paints. It is the block of stone that awaits to be carved by the sculptor. Yet it is also the paintbrush, or the chisel and hammer. Or, perhaps, to be more precise, the programming language is the canvas, and how we write code, becomes the technique of holding paintbrush or chisel.
Tools and materials can be devoid of meaning, merely a prop and device in our daily routines. Yet that is not completely true – we anthropomorphise everyday objects we encounter, unmade, finished or anywhere in between, and impart our residual lived existence in everything we surround ourselves with. Cars that don’t start transform into beasts we try to soothe. Wallpapers and avatars on electronic devices show photos of ones we care about, each a careful curation of our lives. We enjoy the familiar movement wielding the tools we use, each gesture reflecting our mastery (or otherwise) of the tool. We constantly seek affection in the things we have. Are these mental projections impossible if these things themselves do not speak to us about their qualities as we gaze upon, or wield them? As these projections necessary or frivolous, things we can do without? And if necessary, why can’t coding then become but one expression of our lived experience?
I choose to see the act of coding as a material, much like paint, ink on a napkin. An image printed on photographic paper. Pen, pencil marks on a sketchbook, all capturing observations and personified snapshots of our world. Sure, unlike those things, coding demands of me (and every coder/programmer) a particularly unambiguous view of the world, as if expecting that everything can be modelled and broken down into binary logic. The cutting TRUEs and FALSES, the pensive IF conditions that are ultimately dependent on a particular set of expected values, or the LOOPs that inherently impose a temporal quality and repetition to the code we write. The intention of design has often backgrounded the way we think with code, often times in a rather uninspiring, methodological way. Perhaps it is under these draconian constraints that one can choose to look up to see and reflect upon the possibility that code can actually be ‘poetic’.
Consequently, in looking back at how I have developed my own understanding of code, as a creative practitioner, poetry in code may manifest as these four condensations:
- a somewhat superficial process of utilising poetic labels for things like variable and function names (see Example 1 above),
- the beauty of elegant code; the jaw-dropping simplicity of high-evolved and perhaps not necessarily easily readable code,
- a deeper philosophy of how and why structures and logic are written, that act upon both desired, binary input, and leaving other elements to chance (then again, if not a merely a pre-engineered degree of free play?),
- that code is inherently poetic by sheer existence alone – of our attempts to model the ‘world’ as segmented blocks of logic, perhaps a futile attempt in re-creating all but a sliver of reality that vanishes in thin air when applied beyond the context of what the code is meant to resolve. A mirror that never quite reflects as much as the world is able to give…
With this background in my mind, we proceeded to first set aside the mechanics of coding, and come back to it after addressing the experiential elements of When Echoes Find Light to figure out how we could possibly adopt a more poetic framework in writing the code.
The continuation of Charlotte’s project in this work was essentially a detailed unpacking and expansion of the early ideas proposed. Where could people sit? What could be done to detect the presence, and absence of people on the park bench? What gets shown in the form of light, over time? And, most importantly, how could all these ideas be tested and revealed to the public?
I reckon the potential for technologically-laden art to be poetic is often obvious, yet always difficult to pin. Obvious in the sense that our concepts begin in the form of drawings, translating into lines of instruction. This apparently simple translation, however, gives rise to micro-fissures and the dissonance of logical, procedural instructions as mode code is written: the what-ifs, how-abouts, and there-is-another-way-to-do-this revelations that in turn reveal a deeper appreciation of code not purely as mechanical, but as part of the same rich, creative process of making new interactive experiences.
More on the details of the sensing system in a separate post!