Programming Isn't Special
Programming Isn't Special
Originally published on Deciphering Glyph
While the broader creative community has recognized that AI poses a fundamental threat to artistic integrity, the software engineering world is experiencing a strange paradox.
The Great Creative Divide
Across various artistic disciplines, there is a fierce, organized resistance against generative AI. We see this in several forms:
- Labor Action: Writers striking to secure contractual protections against AI replacement.
- Public Protest: Thousands of artists signing open letters to denounce the technology.
- Legal Warfare: A surge of copyright litigation from creative guilds (tracked by dedicated databases).
Despite this, many veteran programmers remain oddly complacent. Even though the industry is happy miserable and the quality of work is suffering, developers continue to integrate AI into their workflows.
The prevailing justification for this surrender is a belief that programming is not Art. The logic follows a simple, functionalist path: If the goal is merely a working product, and the tool produces a working product, the method is irrelevant.
This is a mistake. We must reject AI in programming for the same reason we reject it in art: because programming is, in fact, Art.
The Myth of the "Pure" Artist
Some argue that because code is functional (it does something), it cannot be expressive (art). This perspective stems from what John Berger calls "mystification" in his work Ways of Seeing.
Berger observes how art historians use flowery, ecstatic language—describing "harmonious fusions" and "glowing blacks"—to elevate a painting to a spiritual plane. In reality, the painting was often just a job: a poor artist was paid by some officials to create a standard portrait. It served a mundane purpose, and it did so successfully.
We tend to ignore the functional needs of art (decoration, distraction, status) to focus solely on the emotional impact. This creates a false hierarchy of labor:
| Role | Cultural Perception | Reality |
|---|---|---|
| Novelist | Ethereal, Transcendental | Professional word-worker |
| Journalist | Functional, Mundane | Professional word-worker |
| Copywriter | Lowly, Commercial | Professional word-worker |
There is no magical line separating the novelist from the copywriter; the skills are identical. The difference is merely a result of market opportunity. Working with "mundane" words is simply practice for "artistic" words.
The Aesthetics of Code
Years ago, I called myself a "code poet". At the time, my peers found this pretentious and "cringe," so I scrubbed it from my bios. However, I still believe in the parallel.
My most notable contribution, the invention of Deferred, was not a purely technical decision—it was an aesthetic reaction. I was exhausted by the tedium of "callback hell," where every remote procedure call required passing endless callback and errback parameters.
// The "Tedium" (Callback Hell)
function doWork(param, callback, errback) {
asyncAction(param, function(result) {
asyncAction2(result, function(result2) {
callback(result2);
}, errback);
}, errback);
}
Deferred was intended as a poem about asynchronous execution. It focused on the experience of the developer and the elegance of the solution. While it may not be a "great" poem in the grand canon, it was a poem nonetheless.
The Evolution of Async Patterns
The influence of such aesthetic choices is cumulative. It is less like a single masterpiece and more like a folk epic, where each artisan adds a verse:
To create code that is a deliberate artistic expression, one must first suffer through the mundane. Without the frustration of manual callback management, I would have lacked the motivation to innovate.
Final Thoughts
Most writing is unremarkable; most live music is just background noise in a bar. However, when code is designed with intentional aesthetic purpose, it becomes technologically and socially pivotal.
As Hal Abelson famously noted:
"Programs must be written for people to read, and only incidentally for machines to execute."
If we treat programming as a mere functional utility, we lose the human element. We can quantify the "Internet years" of experience using a simple relation:
But the art of the craft cannot be reduced to a formula or generated by a prompt.
