Book review: The Art of Doing Science and Engineering

I’d read the “You and Your Research” talk maybe five times over the years, the transcript of the one Hamming gave at Bellcore in 1986, the one that turns up on Hacker News every year or so. I’d never read the book it ends up as the last chapter of, which is a bit like having heard a band’s one hit and never the album. A colleague left the Stripe Press edition on my desk in January with a sticky note on chapter 1 that said “you’ll like the bit about knowledge doubling”, and I’ve been reading it at about a chapter a night since.

The Art of Doing Science and Engineering: Learning to Learn comes out of a course Hamming taught at the Naval Postgraduate School near the end of his life. It was published in 1997 and he died at the start of 1998. Stripe Press reissued it in 2020 with a foreword by Bret Victor, which is how I found out it existed, because I’ll read anything Victor recommends (I wrote about his Learnable Programming essay back in 2012, and I still send it to new engineers). It’s thirty chapters, and they’re all over the place: a history of computers and of software, three chapters on artificial intelligence, digital filters across several chapters, coding theory and error correction, information theory, n-dimensional space, simulation, fiber optics, systems engineering, quantum mechanics, and a short chapter on how what you measure changes what you get. The thread through all of it is how he thinks a person ought to go about learning a field and then doing something important in it, and the filters and the coding theory are his worked examples.

That framing works better than I expected. The filters chapters lost me in places (I haven’t done that kind of math since college and it shows), but even when I couldn’t follow the derivation I could follow what he was doing with it, which is asking at every step whether the standard answer is actually right or just standard. He’s interested in how he got things wrong. He tells the story of the Hamming codes the way I’d heard it before: the relay machines at Bell Labs in the late 1940s would detect an error over the weekend and abandon his job, and he got angry enough to ask why, if a machine could detect an error, it couldn’t find where the error was and fix it. What I hadn’t heard is how much he dwells on the conditions that made the anger productive, that he’d been doing the background work in the math for years and was ready to see the problem as a problem.

The n-dimensional space chapter was my favorite, for reasons that are probably specific to me. He works out the volume of a unit sphere as the dimension goes up and shows that it eventually falls towards zero (it peaks at five dimensions, which I had to check on a napkin), and that in high dimensions almost all of a sphere’s volume is in a thin shell near the surface. His point is that our intuition from two and three dimensions is actively misleading when you design things in many dimensions, codes in his case. I read it a week after spending a long evening on embeddings in a small GPT, which live in 384 dimensions in the toy model and thousands in the real ones, and it made a few things click that I’d been taking on faith, like why random vectors in that kind of space are almost always nearly perpendicular to each other.

The AI chapters are the strangest to read this year. He wrote them in the mid-1990s, and a lot of them are about whether machines can “really” think, and how much the answer depends on what you’re willing to count as thinking. That’s the argument going around about ChatGPT right now, nearly thirty years later, and some of his paragraphs could be dropped into a Hacker News thread this week without anyone noticing the date. He doesn’t predict anything like it, and he’s skeptical of most of the AI claims of his time, but his skepticism is the useful kind, where he says what would change his mind.

And then the last chapter is the talk. It reads differently at the end of the book than on its own. On its own it’s a list of advice: work on important problems, keep your door open, think about what the important problems in your field are and why you’re not working on them, sell your work, tolerate ambiguity, and set aside time, Friday lunch in his case, for great thoughts only. After twenty-nine chapters of him doing exactly that with filters and codes and simulations, it reads more like a summary of a method you’ve just watched someone use.

The open door part is the one I’d underline for anyone who runs a team. He says the people at Bell Labs who worked with their doors closed got more done in the short term, and the ones with the doors open were interrupted constantly but ended up working on better problems, because they knew what everyone else was stuck on. I’ve been on both sides of that. In the years I was writing code full time I was a closed-door person, headphones on, and I was proud of it. Now I spend most of my day with the door open, so to speak, and I’m pretty sure that it’s the open-door days that decide what my team works on, and that I’d have been a better engineer back then if I’d taken more of them.

The book has real problems. It’s repetitive, because it’s lectures. It has a lot of anecdotes about Hamming being right while other people were wrong, and some of those are probably true and all of them get a bit much. The chapters on specific technologies like fiber optics are dated in ways that the chapters about thinking aren’t. And it’s clearly a book by one kind of person, a mathematician at a big lab in the golden age of big labs, for people who want to be that kind of person, which isn’t most people in software, me included. He says plainly in the talk that he’s an egotistical person, and a fair amount of the advice assumes you can afford to be one, which I don’t think ages well on a team.

The line I wrote on the inside cover comes from his 1962 numerical methods book rather than this one, but it belongs here: “The purpose of computing is insight, not numbers.” I’ve spent a lot of my career on dashboards that produce numbers nobody acts on. If I could get every engineer I’ve hired to read one chapter, it would be “You Get What You Measure”, which is short and has nothing to do with any of the technical material in the rest of the book. Then I’d hand them the rest and let them skip the filters.