Programming as Art 20-06-2011

I spend a great deal of time writing code. I do this largely because it brings me joy. The process is something that I easily become ensconced within: it envelops me, sends me to far off lands and leaves me stranded to find my way back whenever my mind deems it necessary. For me, programming is a way to escape the doldrums of the more mundane facets of daily life, which is interesting because escapism for many usually involves using less brain power and switching onto an auto-pilot of sorts whereas for me it involves throwing myself into situations where the only way to "succeed" is through increased thought and effort (I'm not quite sure what that says about me as an individual, but it hardly matters). Regardless of reason, the fact is that I find programming to be full of wonder and whimsy and, as I do with most things that I like, I think about it and analyze it as a singular concept from time to time. Lately, my mind keeps coming back to this frame of reference by which computer programming is viewed solely as a medium of art.

Many people find art difficult to define (see: me, who thinks that this difficulty speaks to the value of the subject) and tend to fall back on a "know it when you see it" mode of recognition. Art, as I mean throughout this discourse, can be somewhat described as the expression of aesthetics. This is to say, that Art at its core is the expression of individual notions of beauty. This can manifest itself in a number of diverse ways and is certainly created for a variety of personal motivations, but it is not all vagueries and word-play. There are some very real, examinable phenomena that are born from the framing of an activity or medium as Art. Viewing something so seemingly mechanical and functional as programming as an Art form has some particularly interesting consequences.

Form Versus Function

It is my steadfast belief that in Art, function is nearly irrelevant. Not Art's function, mind you. Not the function of Art itself, which is manifold and includes such critical human functions as communication, imaginative expression, social commentary and so on. Rather, function is irrelevant on the level of an individual work of art. The question about an individual painting, sculpture, performance, writing or whatever is not what the work's function is. The question, rather, is how one interprets the piece. How does the viewer relate to and internally represent the piece? What sorts of emotions are aroused and what feelings are felt? An artist may have a completely different set of aesthetic values compared to her audience and may set out to create a work of art with a specific intent, be it reaction or otherwise. But Art is experienced at the individual level. As such, for a given viewer, the only truth is personal. And this internal truth, this internal assessment and interpretation, is negotiated entirely by form; function thus plays no role. The process of creating Art is essentially the establishment of form.

If computer programming is viewed as Art, then the championing of form over function means programming is no longer tied to the purpose and function of the code. A finished product (source code) is now evaluated for the form of the code itself. Though writing code remains focused around the placement and arrangement of types, keywords, commands, et al., the onus shifts away from concepts such as raw efficiency and performance and toward the aesthetic values of whomever may be viewing the code. A reader may be intrigued by intentional obfuscation, massive and complex data structures, particular design patterns or his own notions of elegance, but the reader is now internally interpreting and reacting to the written code in an entirely individual manner. Though the reader may be "turned off" by code which does not compile, and though most individuals who are likely to examine someone else's code probably do have this personal preference, it is now up to the individual to personally react to such a revelation. From this perspective, if a programmer publishes code which does not compile, then it is no longer an overall death knell to the code itself. To some individuals' opinion of the code, perhaps. But not in general. In this context, programming is no longer distinctly, particularly about producing code which runs and performs some determined function. Code is free to be reacted upon however an individual viewer wishes. And individuals certainly have their own aesthetic preferences.

As it turns out, this is remarkably similar to how code is evaluated in reality. Go to Github, find an arbitrary repository and read through some of the source code. Then do it again. And again. Keep doing this until you have read enough code to have an opinion about the different code bases. You have just viewed programming as one views Art. Everyone has their own notions of what makes code ugly or beautiful, disappointing or impressive. Every individual will interpret a given piece of code differently. Some will be repulsed by code which does not actually run; others will not care one iota. Some will see code that is largely repetitive and think "Refactor!" while others will view the same code and see beauty in the repetition. Even those who claim to only care for how the code performs will readily admit that they have subjective ideals when actually reviewing code: those who staunchly cling to the function of code have an innate eye for form, for they are indeed human. And so the truth is that everyone is already viewing individual pieces of code as Art whether they are conscious of this or not.

The Process of Creation

But Art is not interpretable if it is not first created. Individual artists are given much exposure and adulation because it takes a great deal of work and talent to create Art. The process is important and certainly worthy of examination. Whether it is Jackson Pollock slinging paint onto a canvas so that he can reside within his own work during its inception or Franz Kafka meticulously, painstakingly structuring his sentences for maximum impact and consternation, each artist must actually put in the work to create Art. Artists will often come up with new approaches and new styles. And as artists tread over the same territory that past pioneers once blazed, they will adopt and adapt. But no two artists operate precisely the same: it is an impossibility caused by the great many factors that go into creating something new and original. As such, we often associate artists with their process; we see the artist's name and immediately jump to thoughts of how /he worked, what trends she may have initiated or followed along with, what novelty and impact she contributed to the artistic zeitgeist, and so on.

Computer programmers are no different. The community has created and perpetuated archetypes of programmers that are readily familiarized. Everyone knows about the hacker: the one-person army charging through tough code in the dead of night, fueled entirely by sugar rushes and the sheer thrill of it all. Everyone knows about Mr. Typical: the shirt-and-tie guy gluing together components and putting together code that simply works, mundane as he may appear. Everyone has heard the terms "rock star" and "ninja" (a trillion too many times). But the point is that programmers, like other artists, have a process that they are often identified with. Some are remarkably meticulous and detail oriented while others are big-picture, conceptually-driven folk. Some create by their selves while others thrive in collaboration. Some prefer to build everything from the ground up while others prefer to rely on pre-established APIs and libraries. Each programmer creates their works of art in a unique way.

Yes, programmers are often viewed solely for what software their name is attached to. But many are also viewed for their personality and for their style. And these inform their (often times maniacal and fanciful) process.

And similar to other artistic media with their more readily recognized artistic movements, such as Surrealism or Impressionism, plenty of movements have been seen in the programming medium. Programmers will adopt different standards and styles and paradigms, sometimes along language-lines and other times along the borders of general style. Like painters and writers, programmers are affected by and aware of what their peers are doing and what innovations are being made.

But the point to take away from the idea of programming as a creative process is that it is a varied, erratically flowing, ever-changing goliath. If every programmer worked in precisely the same manner and was indistinguishable in all aspects aside from the finished product, then it would not be Art. It could be the epitome of engineering precision, perhaps. But it would be cold and still. Pure routine. Instead, each programmer is an individual with her own aesthetics, her own approach and her own opinions. Programmers make choices from languages, from environments, from methodologies, from coding standards and from design goals. And also from an uncountable amount of other variables. This, ultimately, is what makes the programmer an artist: like the visual artist, the programmer has a truly unique approach to how his work is brought through to completion and expresses himself and his ideas through his code, which is his medium.

Purpose

The point that Art serves a multitude of purposes was previously mentioned, albeit briefly. But it is my opinion that this is a critical quality that makes Art what it is. Art, in general, has been used as a means of conveying ideas, of entertaining an audience, of inspiring social change, of ritualism and of many other concepts. For the individual artist, creating a work of art can be a process meant to express innermost emotions, to soothe psychological tension, to explore new realms of fantasy, to record daily life or any other personal motive. If all of Art was guided toward one specific purpose, it would not be art. If all Art was meant to propagandize, then it would just be another means of propaganda. If all Art was meant to advertise, then it would just be another means of marketing. But this is not so. It is an intrinsic property of Art as a whole that it can be whatever one makes of it, that it is fully malleable in terms of purpose.

Programming is no different. Many people write code with the intent of running the code and performing some task. But it would be foolish to believe that this is the only motivation for programmers. Some often write code to solve a problem or fill a need: functionality. Some write code to provide an example to other programmers: communication. Some write code to see how far they can push their own abilities and intellect: internal exploration. Some write code to see how far they can push programming itself: external exploration. Some write code because they enjoy the rush of creating something wholly new: joy. Some write code because it pays well: material gain. Programmers, like other artists, are motivated by any number of factors. And Programming, like other forms of Art, serves a medley of purposes and goals.

But, ultimately, why should one view Programming as Art? Does it change anything about the medium itself? No: its qualities are inherent no matter how they are viewed by individual observers. Does it lead to overall "better" programming, or perhaps to more efficient code? No: evaluations of what is good are subjective and efficient code is of course befallen upon the programmer. But, I believe that many of us who self-identify as Engineers, Scientists, Architects or whatever term is in vogue, tend to fall prey to an objective rationalization. We can often become locked within the prism of viewing the world as defined by a set of strict rules, closed to interpretation. And even though we may acknowledge that there are infinite ways to write code for a given task, we may miss the point that this sells programming short. We do not need to write code just to solve a particular challenge or to do a specific thing, and we do not need to look at code and pass a discrete, binary judgment weighted entirely upon whether some pre-determined criteria and specifications are met. This forces us into arbitrary and unnecessary rigidity. It binds us and constrains us into shallow, narrow perspectives.

Instead, we can choose to allow our work and our code to be expressive, to be explorative and to be extensions of our selves. Programming can be a means by which we allow our world to flow more freely. Something so immensely imaginative and creative should not be shackled by the chains of an objective mindset. "Does the code meet this particular benchmark? Does it lend itself well to a large code base? Does it meet the design standards set by X?" These are obviously important questions, but they should not and do not establish end goals. Recognizing programming as an Art form allows the floodgates of expression to open wide. It allows stunning work to be done and awesome new creations to be sprung forth. By viewing Programming as Art, we can fully recognize that the infinite possibilities of expression are at our fingertips.

Why settle for anything less?