Drawing and Programming
Even though one fairly well-known programmer has already pointed out the similarities between programming and art, most people, I would say, still do not appreciate how similar they are.
One thing that struck me recently is how good programmers and good drawers approach their work – and how they differ from the inexperienced. In both fields, people who are skilled know where to begin.
Inexperienced drawers tend to approach the task pretty randomly. Let’s say they want to draw a picture of a cat. They’ll get a piece of paper, a pencil, and maybe even a cat to look at, and off they go drawing. Maybe they’ll start with an ear or an eye, or even the tail. And they’ll progress from that point, filling in a lot of detail as they go. They’ll probably erase a lot of mistakes. Soon enough they look at their eraser-smudged picture and say, “It’s coming out all wrong.”
Their cat doesn’t look like a cat. Its ears are too big. Its feet are way too small for its body. Its tail is going off the page. And there isn’t any room left for the sofa that the cat’s meant to be sitting on.
Experienced artists do it differently. They start with the most basic shapes in rough, sketchy form, making sure they’ve got the perspective and proportions right and that the object is positioned correctly on the page. They’ve studied art, so they know something about animal anatomy and perspective. And they start filling in detail only when they’re happy with the basic form. When they’re done, the picture is balanced, everything fits, and the eye is drawn to the right details.
I think there’s a similar pattern at work in programming. People new to programming often start in the wrong place – with a trivial feature that seems cool, say. And they fill in too much detail too early, before they’ve even written the application’s core engine. Before they know it, they’ve programmed themselves into a corner – they realise that the architecture’s wrong, or that the way they implemented those features depends on too much repetition of code.
Programmers with more experience tackle the core of the application first and keep a close eye on how they will reuse the components they write. They make mistakes, but they sort out the critical ones before they’ve written much, so making changes is relatively easy. It’s also easier to see mistakes when there’s not much code – the core architecture of an application is much easier to understand when it’s not very detailed yet.
One mistake that intermediate programmers can make is to assume that planning guarantees success. It doesn’t. For one thing, plans are usually wrong, sometimes in minor ways, sometimes in major ways. So it’s still important to be able to change the actual code early, and for the early code to represent the core of the application, not trivial high-level features.
In both art and programming, there is an amount of theory that is extremely helpful for producing good work. I think the importance of theory – or “science” – in art is greatly underappreciated. But in both fields, practice is the vital ingredient that leads to an instinctive understanding of where to begin.