When to Code Creatively

This article caught my attention:

Being “rockstars”: when software was a talents/creatives industry 🎭

The post meanders quite a bit, but the central theme is that the author laments the loss of creativity in software development. Their solution, then, is to compare the tools and processes and workflows of creative professionals—musicians, actors, animators—and encourage engineers to find frameworks and technologies off the beaten path.

The idea is provocative and contrarian. But, the comparison is not as favorable as it may initially seem—that is, the creative industry is renowned for its inequality and bias towards top talent, where hundreds of artists and writers toil away for years to try to get their shot to break out. The success that we see is filtered by perhaps the heaviest doses of survivorship bias in our society today; those faces photoshopped on movie posters do not represent the vast majority of actors in the film industry.

And now AI has entered the picture. Generative AI raises the competence floor, and this is most evident in creative domains: rendering artwork, constructing lyrics, writing papers. Nobody would claim these works are great, but they’re surprisingly not bad, and they can be credibly compared to amateur artistry or perhaps something that a student would create en route to learning their craft.

Real-world use cases of Github’s Copilot have revolved around generating predictable code: taking familiar IDE autocompletion and function generation to the next level in sophistication1. Its role isn’t exactly to delight and surprise the user; the tool is more useful when its code is reliable and easy to understand, ideally verifiable not only at runtime—but on sight. In other words, AI works best when it’s boring, but boring is good when utility matters.

That’s not to say that coding is not a creative endeavor: there is a wide array of languages, frameworks, libraries, paradigms, design patterns, and styles to tackle any problem where code can optimize or automate a solution. Where the analogy with other creative industries breaks down is that the value of software is not in its aesthetics, or its performative presence: software’s primary value is its utility2. The premise of the above post is flawed from the beginning, as the goal of most software and therefore most software engineers is to create business value. It’s practically a rite of passage for programmers to first learn about various clever ways to code3, then subsequently realize that their cleverness is more annoying than useful.

Of course, it is precisely this utility that makes our field an attractive career option. It’s rare to find a discipline that has room for some creativity, but also drives added efficiency across so many other disciplines that worker demand—and salaries—have hardly waned in a decade4. It wasn’t too long ago that people were encouraged to learn to code, irrespective of disposition towards programming; after all, it was easy to get started, and a solid payday was waiting for those who attained professional capabilities.

I’d like to think that there’s a time and a place for code to be both expressive and utilitarian. I often compare coding to writing, and this is perhaps another analogous trait. There are multitudes of reasons to code and write, and what you’re trying to get out of the activity—the motivations and resulting artifacts—may very well determine your style and approach.