Hackers & Painters, 20 years on

The title essay, “Hackers and Painters”, is dated May 2003, which makes it twenty years old this year. The book came out from O’Reilly the following spring, collecting it with fourteen others, most of them written between 2001 and 2004. I first read it not long after it came out, probably on a work machine I shouldn’t have been reading it on, and I hadn’t opened it since. I picked it up again this month because I’ve been trying to work out what I actually think about programming now that a model writes a fair amount of mine, and it seemed like the right book to argue with.

What held up

“The Other Road Ahead”, from 2001, is the essay I’d hand someone who wants to know whether Graham could see the future. It argues that software was going to move from the desktop to servers, delivered through the browser, and that this would change how it’s built: you release whenever you want, many times a day, you see bugs as users hit them, you fix them in an hour, and you never ship a CD. In 2001 that was a contrarian position. I was still in school then, writing Windows desktop apps on the side, and if I’d read it at the time I’d have argued with it. Now it’s simply a description of my job. Every company I’ve worked at since has been a version of it, and the parts he got most right are the cultural ones, like the small team shipping constantly, more than the technical ones.

“A Plan for Spam” holds up for a different reason. It’s a practical, almost homely essay about using word probabilities to classify email, and it’s how a lot of people my age first met Bayes’ theorem doing something useful. Graham reported catching well over 99% of his spam with very few false positives. Reading it after a year of large language models is odd: it’s the same basic move, learning from the statistics of text rather than writing rules by hand, at about one-billionth the scale.

The line from the title essay that I’ve quoted most over the years is still the best one in the book: “A programming language is for thinking of programs, not for expressing programs you’ve already thought of.” He uses it to argue for languages and tools that let you sketch, change your mind and rewrite, the way a painter does, rather than ones that make you specify everything up front. I believed it in 2004 and I believe it more now.

Blub

“Beating the Averages” is the one people argue about. It’s the essay where Graham says Viaweb, which Yahoo bought in 1998, beat its competitors partly because it was written in Lisp, and introduces the Blub paradox. A programmer who knows a middling language, Blub, can look down the power continuum and see that weaker languages are missing things. Looking up, he only sees weird languages that have features he doesn’t think he needs, because he thinks in Blub.

I disagreed with this essay for years, mostly because I didn’t know Lisp and the argument felt like a club for people who did. Then I reread my own post from 2010, where I describe telling a professor that Python was a “typeless” language not worth learning, because C++ was obviously the best language ever. That’s the Blub paradox in one paragraph, written by me, about me. I still don’t think Lisp is why Viaweb won (small team, the right idea early, and Graham himself seem like better explanations), but the paradox is real, and I’ve been on the wrong side of it more than once. C# with LINQ and lambdas changed how I wrote code in ways I couldn’t have predicted from C# 1.0, which is the paradox from the inside.

What I’m less sure of

The painter comparison is the weakest part, and it was when I first read it too. “What hackers and painters have in common is that they’re both makers,” he writes, and that’s fair. But he goes on to treat programming as primarily an individual creative act, and most of the programming I’ve done, and nearly all of what I’ve managed, is a team building something together over years, with code written for the next person to change. He does say in the same essay that empathy is probably the most important difference between a good hacker and a great one, and quotes Abelson and Sussman on programs being written for people to read, which is the part of the essay I’d actually teach. The painting is more romantic, and less useful.

“Why Nerds Are Unpopular” didn’t land for me then and doesn’t now, mostly because it’s so specifically about American high schools. I went to school in India, where, at least at my school, exam marks mattered more than popularity, and the essay reads like anthropology about a place I’ve only seen in films. “How to Make Wealth” is clear and persuasive about why startups can compress a working life into a few years, and having spent most of my career at startups, I’d add that the compression comes with a much higher chance of producing nothing, which he does acknowledge, but briskly.

Reading it in 2023

It’s strange to read “The Hundred-Year Language” this year. Graham asks what programming languages will look like in a century, and his answer is roughly that the core will get smaller and more mathematical while hardware makes efficiency matter less. It doesn’t imagine that a chunk of programming would move into English, typed into a chat window, and I don’t blame it. Nobody I know imagined that in 2003, or, honestly, until about a year ago.

But I think the “thinking of programs” line survives it. When I use ChatGPT or Copilot well, it’s because I’m using it to sketch: try three approaches, throw two away, see what the problem actually is. When I use it badly, it’s because I’ve asked it to express a program I haven’t thought through, and it does exactly that, fluently. Twenty years on, the advice in the book that still matters most is the one about the order of operations: figure out what you’re building by building it.

If you’ve never read it, read “The Other Road Ahead” and “Beating the Averages” first, they’re on his site. The book is worth owning for the title essay and the notes, which are better than you’d expect.