Ever since Gianfranco Berardi started blogging again a few posts ago, I have been in general agreement with what was written about each time. We’ve had a back-and-forth on a few things covering narrative and stories in games in the comments, and I was even a part of the on-going conversations about backlogs and sales of game collections. All general, of-the-moment dialogues about important concerns within the greater games community and industry.

Of course, we each come at topics from different angles. I have a decade of academia behind me and, what with being a graduate student, I tend to think of things in terms of students and teaching. I’ve personally spent a great deal of time trying to bridge the humanities with the sciences. To me, then, declaring something not creative is paramount to dismissing its importance. Creativity is at the root of our humanity. It is what allows us to pierce the wonderful and concoct the seemingly bizarre from our individual weird.

The Necessity of Failure

If there is one thing I can impart to my own students, it is this: you will fail. When you first try to take on some new topic, be it writing or even coding, you will fail. However, just because something doesn’t work the first time doesn’t mean to give up. We all fall down the first time. It’s the next step, trying again and revising, that matters most. Writing is, to paraphrase a quote, 99% revising after all. It’s the same with coding. They are, in my mind, the same.

So, to question if coding can be creative is, to me, the same as question if writing can be creative. Of course programming is creative! All language writing is the act of creation. To record thoughts and set down logic to a madness of symbols is to mold them, to construct some sense into them. That code is then parsed, compiled, or read does not change this. It is, at its base, all encoded language. It is all creativity.

The Difference between Using and Mastering

However, what Gianfranco is getting at, I feel, is not that creativity doesn’t have a place in programming, but more that code is frequently graded on efficiency and simplicity. Often, in workplace settings, elegance is not as important as code that follows the standards or protocols in place. There are set goals that influence behavior and restrict the urge to deviant too far from them. We might, to put on my teacher hat on for a moment, call this a normalizing pattern. The incentive to write “creative” code is highly reduced.

To write code that solves a more generalized problem isn’t as important as the problem in front of you at any one time. Much of the work done in what is considered a professional setting is solving problems one after another. It is about knowing your tools and applying them in what Gianfranco labels, quoting someone else, “engineering, not creativity.” Knowing how long it might take to solve the problem, what is involved, and what tools to apply is more important than writing beautiful code. The goal is functionality, not perfectly constructed code. It’s the speed–accuracy trade-off, or, put another way in some circles, “worse is better.”

There is a worry that comes from this too. As people become accustomed to certain knowledge domains, they specialize. With this often comes a loss in other areas. It’s a form of min-maxing. By becoming very good at solving certain problems, people sometimes forget other domains or lose interest in them. The creativity that manifests in being really good at “engineering” is seen as years of experience, as it is in part, but it is also a specialization too. All investment comes at a cost.

Experimentation before Solutions

I think creativity in code is just another way of saying, “I’m guessing that this might work. Let’s see what happens.” It’s like throwing things into a fire and observing the results. It’s not creativity so much as experimentation.

When I learned about design patterns, entire concepts were made clearer to me, and my programming capability improved. I didn’t have to be as creative to write code to solve a problem or accomplish a task. If I’m ever trying to be creative while writing code, I think it says more about my lack of knowledge in the area than with the nature of programming.

I feel as if the sentiment behind this is of lazy coding. Instead of coming up with a solution, carefully testing it, revising as needed, and then finally releasing it, we all risk this. It’s the same, to compare this to writing again, of trying to put something together the night before it is due. This can sometimes force creativity through the application of stress, but it isn’t the best way. It never is. Throwing ideas together, be it in code or writing, isn’t solving the problem, it is hoping no one will see through your hastily thrown together illusion of work.

Revision in writing, as well as in programming, is the key. Creativity drives this process. However, its purpose is experimentation itself. Trying, failing, and trying again.

It is very rare to hit upon a solution on the first try and even rarer still for it to occur a second or more time. Creating and testing writing or code is the process itself. Thinking up something that might work, seeing if it does, and then running it through all the normal tests is the normal procedural. This is creativity. This is experimentation.

This is also learning. We fail. We try again. Maybe we fail again. But we keep going, applying the lessons of our failure to better ourselves through each iteration.