The Experience Of Being Creative

Software developers know it is common, if not the norm, to be asked to do something they have never done before. The solutions will somehow appear in their mind. One random thought leads to another and for some reason that leads to an idea that solves a problem.

Creativity in programming faces a world of black and white truths. It is often obvious when something is not implemented correctly because it just does not work. Unfortunately for the programmer there is all the reason in the world to think the software is wrong. Code does exactly what we tell it to and saying exactly how something should work is notoriously error prone.

There has been a long standing discussion in the programming world on the value of various forms of strictness. On the one hand, some languages require very specific statements that can be tricky to write but often guarantee the software performs well. On the other hand, some languages feel more like duct taping one idea to another and does so towards the goal of making ideas easier to express.

In a great talk on creativity, John Cleese describes creativity as not a talent but a way of operating. It cannot be explained, he says, but it can be performed somewhat reliably with some consideration for how it works. John identifies two primary modes of creativity, the open and the closed modes.

The open mode is where ideas get thrown around, free association is encouraged, and there is no such thing as a bad idea. The purpose of the open mode is to get as many ideas up for consideration as possible. One of the challenges of being in the open mode is having an environment where the open mode thrives. To understand a good environment, we can identify a few things that break the open mode: a snide comment, a "well-actually"... In general, someone simply has to make a negative contribution of some kind and the open mode will end.

The closed mode is the detail oriented, perfectionist side of being creative. The purpose of the closed mode is to evaluate everything the open mode found and form opinions, sort the good from the bad, and find all the errors where ever they may be. Declaring something is incorrect is both fine and encouraged during the closed mode. It is the time to put together the best of the ideas and nudge them towards perfection as much as possible.

Pondering a problem requires going between the open mode and the closed mode. While the open mode produces a lot of possibilities the closed mode can then be used to narrow the focus. It is then best to switch back to the open mode to receive feedback then again switch to the closed mode to consider it all. And there, something is being created.

Many things can work against creativity. The open mode's big flaw is that it can be closed so easily. The big flaw of the closed mode is that it has enormous power to stifle productivity. An example is when some code is never quite good enough.

Numerous studies have reported that humans are notoriously bad at managing their time and programmers are no exception. Each faces a time when they were too optimistic about how long something would take. Maybe a single component took twice as long as expected and, because they were new to programming, they didn't budget extra time for absorbing mistakes. This is par for the course for more experienced programmers. Consider that programmers are often asked to do something they've never done before and must rely on their creativity to somehow figure it all out.

Time must be made for the oscillation of the open and closed modes. Someone on a creative endeavor must essentially think long enough to find a great idea. A simple test for knowing if one has thought long enough is by whether or not an idea inspires them to action. Some folks will build too soon, others never quite get around to it, and somewhere between is the right mixture of discovery and implementation.

An environment must be available for one to be in the open mode long enough to find the great ideas. This environment should be as free of distractions as possible. Cleese captures this sentiment nicely by pointing out that it's easier to do trivial things that are urgent than it is to do important things that will take a while; and it is easier to do little things we know we can do than it is to do big things we're not so sure about.

Most of the discussion so far has been about creativity with some programming details sprinkled here and there. If we go further into programming, we can find the natures of open and closed thinking across the language spectrum. In one area we have languages that are very forgiving of mistakes and sometimes lead to conditions that make no sense, yet sort of do something. In another area we have languages that require great precision, operate quickly and safely, but require a lot of study to understand.

Along the spectrum of specificity and error handling is a tendency towards being in the closed mode. A strong type system will say you're wrong more often than no type system. Understanding Haskell requires more upfront knowledge than Python. In other words, languages that promote the open mode also tend to be less rigorous.

Creativity is not a talent. It is a process that requires awareness of modes and lots of time. Consider that if you go from idea to typing, you have skipped the open mode. And consider that if you edit a section over and over and over, you are in an infinite closed mode loop. The most productive programmers know how to balance this and are more productive exactly because they found better solutions.