The canvas

In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them.

— The Pragmatic Programmer, D. Thomas & A. Hunt

Thomas and Hunt were writing in 1999, and the comparison has aged well enough that it now circulates without attribution, which is the usual fate of a good analogy. It is worth slowing down on it, because the three words they use — science, art, craft — are not decoration. They are a claim about what kind of activity this is, and the claim is more uncomfortable than it looks.

Science is the part everyone is comfortable with. There are invariants, complexity classes, type systems, things that are true whether or not the team believes them. Art is the part everyone likes to invoke at conferences. Craft is the part nobody wants to pay for.

The material that offers no resistance

A painter works against a material. The pigment dries at its own speed, the canvas absorbs what it absorbs, gravity has opinions about a wet surface. David Pye called this the workmanship of risk: the outcome is not predetermined by the plan, it is determined continuously by the hand and by the material pushing back.

Software has almost no material resistance. Nothing dries. Nothing sags. There is no grain to work with or against. This sounds like an advantage and it is the source of most of the trouble, because every constraint in a software system is a constraint someone chose. Where the carpenter can blame the wood, we can only blame a decision we made three quarters ago and have since forgotten making.

This is why the craft part matters more here than in trades where the material does part of the disciplining for you. When the medium imposes nothing, the discipline has to be imported.

What the painting hides

The analogy breaks in one specific place, and the break is instructive. A painting gets finished. Somebody decides the last brushstroke has happened, it is varnished, it goes on a wall, and from that moment its job is to be looked at.

Digital products are never varnished. Peter Naur argued that a program is not really the text of the program at all; it is a theory held by the people who wrote it, a theory about the domain and about why the code is shaped the way it is. The text is the residue. When the people leave, the theory leaves with them, and what stays behind is a canvas whose brushstrokes nobody can explain any more.

That is a strange kind of artefact. It looks finished and behaves like a rumour.

It also means the blank canvas is mostly a fiction. Very few teams start from nothing. They inherit a codebase, a payment provider they cannot leave, a data model shaped by a market they no longer serve, and a few thousand users with habits. The real skill is not deciding what to put on an empty surface. It is deciding what to do with a surface that three previous painters have already worked over, none of whom left notes. Christopher Alexander spent his career on exactly this problem — how form gets selected under constraints you did not set — and reached conclusions considerably less cheerful than a metaphor about blank canvases suggests.

Where the analogy earns its keep

For all that, I keep coming back to it, for one reason: it gets the direction of causality right.

The organisational default is to treat building as execution. Decide, then build. The plan is where the thinking lives and the building is where the thinking gets typed up. Anyone who has painted anything knows this is backwards. You find out what the picture is by painting it. You discover the composition was wrong at the point where you have already committed enough paint that the discovery is expensive.

Brooks made the same observation with less charm and more evidence: the hard part is not writing the code, it is arriving at the conception, and the conception keeps changing because building it is what teaches you about it. Which is why software products are as difficult as they are — not because the typing is hard, but because the learning and the committing happen in the same gesture.

Richard Sennett's version of craft is useful here because it refuses the romantic reading. The craftsman is not a free spirit. The craftsman is someone who has spent long enough with a material to have earned judgment about it, and that judgment is the only thing standing between a plan and a mess.

There is a cheap version of this analogy where product work becomes self-expression, the roadmap becomes a canvas, and everyone gets to call themselves an artist. That reading is worth resisting. You do not paint for yourself. Someone has to live inside what you make, use it on a bad morning, and pay for it. The canvas belongs to them.