Category: rant

How we program

I’ve always wondered how we do programming. Code can be so clean and straight-faced, but when you step back and try to think about how you write it, a darkness descends. It’s tempting to think that your brain is working like a computer program, transforming a symbolic problem into a textual answer as sourcecode. But I don’t think that’s what is going on at all — if problems came specified in formal language, then programming would be a very different experience. We instead start with a mess, and try to find all the problems in it through the process of designing and writing code.

There’s a lovely paper called Mental imagery in program design and visual programming by Marian Petre and Alan F. Blackwell, with many great quotes from programmers trying to introspect on their work. Here’s some tasters:

“ … it moves in my head … like dancing symbols … I can see the strings [of symbols] assemble and transform, like luminous characters suspended behind my eyelids … ”

Programming is a dance of symbols behind the eyelids. Write that into a QA standard.

“It buzzes … there are things I know by the sounds, by the textures of sound or the loudness … it’s like I hear the glitches, or I hear the bits that aren’t worked out yet … ”

This programmer is describing re-purposing their sense of hearing to produce computer software. Quick, strap them into an fMRI machine!

“values as graphs in the head … flip into a different domain … transform into a combined graph … (value against time; amplitude against frequency; amplitude against time) … ”

Hmm programming as relationships within abstract spaces, and relating those spaces to one another. A nice model for thought in general, perhaps?

“It’s like describing all the dimensions of a problem in 2D, and in the third dimension you’re putting closeness to a solution.”

Another, rather different spatial approach, where goodness of solution is somehow represented by something like height.

“ … oh, that happens over there … it’s on the horizon, so I can keep an eye on it,but I don’t really need to know … ”

Exasperating, and sums things up nicely. This kind of introspection is just too hard, so much of these thought processes are entirely sub-conscious. For example you try for hours to solve a tricky problem, give up, then the answer pops into your head while you’re cycling home, otherwise thinking about dinner.

That said, while the above evidence is purely anecdotal, it gives some hints about what might be going on. I like to think that programmers tap into a general human ability to organise a messy world into far tidier problem spaces, and find their way around such spaces in much the same way as they do when bumping around in a pitch black room…

Following your imagination

This entertaining article supporting test-first development has been playing on my mind. The article is beautifully written so it is easy to see the assumed context of working to deadline on well specified problems, most probably in a commercial environment. It saddens me though that we accept this implicit context across all discussion of software development practice all too easily.

Here’s a nice illustration from the article, which appears under the heading “Prevent imagination overrun”.

unit-test-graph.png
Diagram © lispcast, some rights reserved

So there is a fairly clear reason not to write any tests for your code — you will take in more of the problem domain without such directive constraints. What you are left with will be the result of many varied transformations, and be richer as a result. You might argue that this is undesirable if you are coding a stock control system to a tight deadline. If you instead take the example of writing some code to generate a piece of music, then you should see my point. The implicit commercial context does not apply when you are representing artistic rather than business processes as code.

In fact this notional straight line is impossible in many creative tasks — there is no definable end goal to head towards. A musician is often compelled to begin composing by the spark of a musical idea, but after many iterations that idea may be absent from the end result. If they are scoring their piece using a programming language, then there would be no use in formalising this inspirational spark in the form of a test, even if it were even possible to do so.

What this boils down to is the difference between programming to a design, and design while programming. Code is a creative medium for me, and the code is where I want my hands to be while I am making the hundreds of creative decisions that go into making something new. That is, I want to define the problem while I am working on it.

While “end user programming” in artistic domains such as video and music becomes more commonplace and widely understood, then perhaps we will see more discussion about non-goal driven development. After all artist-programmers are to some extent forced to reflect upon their creative processes, in order to externalise them as computer programs. Perhaps this gives a rare opportunity for the magic of creative processes to be gazed upon and shared, rather than jealously guarded for fear that it may escape.

This post is distributed under the attribution share-alike cc license.