Arts and Programming

Back in University, I took a joint honours in Pure Mathematics and Theatre Arts. Whenever I’d tell that to people in University, they’d look somewhat askance and ask, “why that combination?”

And I’d reply that I felt that the two disciplines helped to exercise both halves of my brain: the logical and the creative. I think those are two important abilities for computer programmers: I’ve long felt, as many others feel, that programming is a creative skill, and requires imagination as well as rationality.

I’ve been thinking, recently, about some of the things that have been taught to me by teachers in arts disciplines, and wondering how those things relate to work.

First example: I was taking a course on improvisational theatre (Improv). One of the things that theatre is very deliberate about is warm-up. Stretching exercises, bending, and reciting specific phrases to get your mouth in the habit of properly articulating words. Improv also uses some quick games to warm up people’s imagination.

And that’s something that I think is worth dwelling on: theatre, like so many things, has a culture. And the culture of theatre includes a belief that imagination is a skill. And it can be improved or atrophied based on use, and practice. In Improv, everyone believes that a half-hour to forty-five minutes of warm-up and creativity games (together, as a team), will make for a better Improv session, than if those things had been skipped.

So now I ask myself: if programming is a such a creative skill, what do we do to “warm up” our imaginations before a long day of coding?

To be honest, I think that the culture of our organization doesn’t include that idea. Often I find myself sitting through staffing exercises saying “so-and-so is good about X, so I think they’ll fill this particular need,” or “we have a lot of people of this type, but nobody who’s good at Y”. I think, often, our language reinforces the idea that creativity and other “meta-skills” are just innate attributes of people. They are simple, unchanging facts. Some people, we seem to think, are just talented in ways that others aren’t.

Speaking for myself, that idea is anathema to me.

And then I was thinking about another course I was taking, recently. A coupl’a years ago, I was taking a course on cartooning. One of the things I really enjoyed about my cartooning instructor was that he never really believed that discussion of talent was at all useful when it came to teaching the subject.

He often explained the he felt that “talent” was a relatively recent way of talking about art: that for most of history, people learned to be good artists the same way one learns any other skill. You apprentice with a professional, and you practise, practise, practise.

In his mind, one became a good cartoonist by doing these things:

  1. Look at the work of other good cartoonists
  2. Try to make reproductions of those cartoonists’ work
  3. Draw every day. Carry a big sketchbook with you and draw things that you see. Draw a chair. Draw a tree. But draw. every. day.
  4. Try out many different options in cartoons you draw. (He showed us thumbnail sketches from Art Spiegelman’s MAUS. Spiegelman would create fifty different layouts for each page. This is cartoon refactoring!
  5. Keep drawing.
  6. Pay attention to what works: if a cartoon really communicates a strong sense of sadness, or comedy, or what-have-you, notice it, and try to use elements of that work to create your own cartoon that captures the same feeling. Discover why a particular angle, or use of dark space, makes the scene effective.
  7. Build up a mental (or physical) catalogue of techniques like that, so that you can draw on them when you create your own cartoons

I think that this is a good model for becoming a great programmer. Look at other programmers’ stuff. Run, reproduce and/or refactor those programs to the point of really understanding why it works. Program every day (not, by the way, program 10-6 every business day). Start keeping a mental list of techniques

I was chatting with Sue yesterday, and she said something to the effect that it’s good that we have a culture where we are forced to read each other’s code. And I replied that I think that we do, except only when we’re looking for something very similar to what we’re currently working on. When faced with code unlike anything we’ve ever seen before, we’re more likely to go to the person who wrote it than we are to try to understand it.

This is, in my opinion, crucial: we learn from understanding the techniques of others.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply