|2b|

"It’s like doing a jigsaw puzzle where you can change the shape of the pieces as well as their positions."

This is one man's description of what programming is like from the perspective of the programmer. From a comprehensibility standpoint, I think it's pretty good.

Programming, as a function, is something that mystifies the vast majority of the population; as a programmer, I think it's safe to say that even the majority of the people paid to program have no real idea what they're doing on the conceptual level. If you ask a bunch of programmers "what do programmers do?", you'll likely hear a range of replies from the uber-technical ("transliterate a requirement") to the basic ("implement a process") - and that's just on the actual work performed. If you ask a bunch of programmers *how* they do what they do, you likely won't get any really substantive answer at all.

It "should" be simple, really. All programming languages consist of a basic series of operations and relationships; such series are notably finite and often fairly short, when you actually look at the principles - offhand, I'd say there are less than 200 specific relators covering all programming languages (though syntax often varies wildly), and probably less than 20 if we are willing to use abstraction. All we're really doing when we program is combining various objects/concepts/"things" using these relators.

Of course, "all" a painter does is put pigment on canvas, and pianists only have 72 or so notes with which to play. The complexities of painting and composition come not from the tools or options but in how those tools and options are utilized. There's a creative step, an inuitive moment or leap that takes place. This leap generally takes things we understand or comprehend and presents them in ways we do not expect and is usually founded in describing the relationship between concepts that heretofor have not been understood as related. The photographer captures profound emotion in a simple flower; the painter portrays the subject from a prespective never before seen; the musician writes a motif that recalls a spring rain.

The fundamental principle here is an understanding - albeit usually subconsciously - of relationships. To quote Lewis Carroll, why is a raven like a writing desk? The first act of creation is in establishing the existence of the unknown - the fact that something is waiting to be created. Usually, this understanding then provides the context for creation - in essence, understanding what is missing gives us the first step in understanding what it is we want to create. We then have to frame that desire in the context of our medium - the semanitcs of creation are different for photography, music, painting and poetry.

We can formalize these steps as lack (or problem), desire, and semantics. What we usually think of as the "creative step" in the series is "desire": the conceptualization of what it is we're trying to achieve in some kind of workable or formal structure. This is the "hard part", as it requires both clarification of the problem as well as realizing the limits of the semantics even while we work separately from either.

And this is the step in programming that most people don't understand. Semantics, in programming, is merely the syntax of the language - something even text editors can manage, so obviously not a major issue intellectually. The "problem" is usually input from a client or customer, though oftentimes such individuals need help clarifying exactly what it is that is wrong; still, this is a piece that is easily managed through standard processes. It is the clarification and implementation of desire that requires abstraction and the mental jigsaw puzzle: figuring out how to fulfill the needs presented in the desire under the limitations of the semantics, when there are quite literally infinite potential solutions but only a few practical ones.

Programming is, for all its technical requirements, a creative act not terribly different from any other artistic pasttime. Just like other arts, the moment of inspiration in programming cannot be laid out in a procedure or taught in a classroom. One can teach someone to use a camera, but one cannot teach someone to take inspiring photographs; one can teach someone English, but one cannot teach them to write beautiful poetry. One can teach programming languages, syntax, and grammar, but one cannot teach effective programming.

Obviously, the better a person is a coder (or photographer, or linguist, or...), the wider the range of tools and options that are available to that person while programming (or photographing, or writing, or...) However, as artforms, all these rely on moments of inspiration. One can encourage the mindset needed to have such moments, and train oneself (or others) in the sorts of abstract daydreaming that forms the basis for them, but one cannot explicitly teach inspiration itself. It comes naturally or not at all.