Programming is a Creative Activity

How to treat people who write code well

At first glance, the work of a ‘creative’—e.g. an artist, designer, writer—and a ‘programmer’—dev, engineer, IC etc.—are very different. Certainly you’re likely to find the cultural centre of two groups of people in these fields to be quite different from each other.

At a glance the work may seem quite different too: a visual artist will spend their day sketching, possibly without the aid of digital tools at all, in order to create visually aesthetic, meaningful visual works. The programmer on the other hand is solving a complex logic puzzle with lines of code in a very rigid environment, they are probably working to a specification detailing exactly what it is they need to produce and potentially even how.

If you look at how creatives are hired there are very different approaches too: At a large agency you will find creatives are rarely hired alone, instead partnerships or even teams of people will be interviewed and hired together. There is so much value bound up in creative partnerships that breaking them is not beneficial for anyone involved, whereas programmers will often change teams and companies frequently, potentially switching languages, stacks, industries all at once as they do so.

However, I would propose that programming is as creative as any of these other fields, and programmers (I use that term as a blanket to cover those who primarily code as part of their job) and the companies that employ them might create a better, more productive working environment if they were treated as such, and used some of the same approaches for hiring and managing them.

One of the places where people fail to see this parallel is due to—broadly speaking—the differences in personalities you will find in these roles. I am going to talk in big generalisations here!

I know, and I’m sure you know many people who break this rule, but on the whole you’d have to agree that if you were to do a Myers-Briggs (or whichever personality horoscope you prefer) you would find that on the whole you’d find programmers on the more analytical side of the axis, and your traditional creatives on the more emotional.

This confuses us, because in our minds we’ll typically see emotionally-driven creatives and analytically-driven programmers, and yet the work that programmers are doing is fundamentally just as creative in nature.

Another confounding factor is that the output of a traditional creative’s time is typically something that is tangible: an image, some music, copy or prose. The output of the programmer’s time is likely only really understandable by their colleagues.

Sitting at a text editor or IDE a programmer with nothing more than an idea in their head will wrangle it into being through their own insight and creative will. Most programmers will have an urge to make, to build (an instinct that often needs to be reigned in!), and that’s what got them into it in the first place.

The tools look very different, the ideas are a very different shape, and yet the fundamental act of creation is the same as someone turning their ideas into prose, copy, sound or visual media.

Many of those who write for a living have a personal project like a book they work on in their spare time. Someone with a job in UI design may have an artistic side project as an outlet for the creativity which has its wings clipped by company requirements. Do you know programmers who also work on creative projects outside of work?

Another misdirection (for now at least) is money. Getting paid to write is hard, and getting paid to write truly ‘creatively’ (beyond e.g. marketing copy) is harder still. Salaries are often low, creative jobs subsidised by others, and only those who make it to the top of the tree, who get their big break—their book gets published, their art gets noticed—will make serious money from their passion.

For the past few decades, programming has been in such high demand it is easy enough if you are moderately profficient at it to command a comfortable salary with good perks and great job security. Of course it was not always thus, with programming being considered a secretarial role in the very early days of computing!

This disparity in status can make the work that programmers are doing feel more important, more serious, more valued compared to the work of other creatives.

It is interesting that in the latest leap forward in AI technology many creatives are nervous for their jobs - LLMs like ChatGPT can convincingly write meaningful-sounding prose to a specified style. Stable Diffusion and other visual AIs can produce images to a very tight spec instantly, mimicking any style and with any arrangement of subjects.

For the first time it also seems that AI is coming for the jobs of programmers themselves too - ChatGPT can write code to spec in a variety of languages, explain how it work, and fix its own bugs when prompted. It is likely that it will only get better from here. We may be entering a new chapter very soon where programmers and creatives find themselves on equal footing again.

But for now at least nothing seems to be changing yet. The tools may change but we will still need people who can understand them, and while the job of programming may change, in the past when massive labour-saving inventions have come along, the result has been more work put into other things, and there is no shortage of demand for software.

So how can an organisation do better by its programmers? I’d suggest in the following ways:

• Respect flow work

  All programmers know about flow - to be deep in a difficult problem, with all the context in your head at once. This state is hard to achieve, and impossible to achieve with distractions. Artists and writers attend retreats to find the time and space for big thoughts. Perhaps your programmers could benefit from some extended periods of thinking time too.

• Don’t disrupt great partnerships

  A team that’s working well together can be hard to find, and it’s difficult to engineer. Sometimes the magic just happens and you have a team that’s firing on all cylinders. Reject the temptation to spread that good practice around and leave them to get on with it. Just as great creatives form great partnerships, let your programmers do so too.

• Understand & manage the emotional impact of creation

  The IKEA effect is a bias everyone displays towards things they themselves have created, or had a hand in creating. You instinctively feel ownership over something you have put effort into. When managing programmers, be aware of this. All code typically has a short lifespan of a few years at most. Deleting, deprecating, decommissioning things that you have put months or years into creating can be a surprisingly emotionally hard thing to do. Understand this toll.

• Give freedom but with clear boundaries

  Creation is exhausting, an in particular with programming there are many decisions to make, even on a single line of code. What to name a variable? Use a case statement or if else? Where to handle a potential error? This is exhausting, and one of the ways to help programmers out is by making as much of this as obvious as possible with clear, concise style guides, automatic formatters, and clear guidance about How Code Is Written At Company. But it’s a fine line - too proscriptive and it can feel like all the creativity has been sucked out of the job, and that’s probably the motivation for doing the job in the first place.

• Understand that creation is a two-way process

  You cannot be a writer without reading voraciously. You cannot paint without appreciating the work of others. So it is with programming. However unlike works of great literature or art which are freely or cheaply available to consume and learn about, most code is tucked away within the organisations that own it. However, the masterstrokes, the key ideas, the clever hacks live on in the heads of the programmers who worked there even once they have moved on. Encourage programmers to share not just what they are working on now, but the best things they’ve worked on before (while respecting their NDA’s, of course).