Book review: The Soul of a New Machine

I just reread The Soul of a New Machine. It’s at least my third time through it, and every time it’s a different book because I’m at a different point in my career.

If you haven’t read it: in the late 70s Data General is losing ground to DEC, which has just shipped the 32-bit VAX. Data General’s official answer is a big new project at a separate facility in North Carolina. Meanwhile, back at headquarters in Westborough, Massachusetts, an engineer named Tom West puts together a small, unofficial team to build a 32-bit machine of their own, code-named Eagle. Most of the team are fresh out of college. They have no real mandate, a deadline nobody believes, and a basement. Tracy Kidder was embedded with them for the whole project and the book won the Pulitzer.

The first time I read it I was in my early twenties and I identified completely with the “Microkids”, the young engineers writing microcode until four in the morning. Being handed an impossible problem and disappearing into it for a year was the most romantic thing I could imagine. Honestly, it still sounds pretty good.

This time it was a book about Tom West, and from that angle it’s a lot more uncomfortable. West is brilliant and he gets the machine built. He’s also deliberately distant, keeps the team in the dark about the politics, and more or less lets them believe they’re on their own so they’ll fight harder. Having run teams myself now, a lot of that is hard to read. Some of it obviously works, shielding a team from company politics is real and valuable work. But it depends on a steady supply of young people willing to burn themselves out for a feeling, and the book doesn’t hide the cost. By the end, a lot of the key people are exhausted or gone.

Even so, I use ideas from this book all the time. The big one is “signing up”. West’s recruits aren’t assigned to Eagle, they’re asked whether they want to sign up for something hard, knowing what it’ll cost them, and Kidder argues that act of commitment is what drives everything after it. When I hire I think about this a lot. The best engineers I’ve worked with weren’t always the most talented ones on paper, they were the ones who’d decided the problem was theirs.

Then there’s the pinball game. One of the engineers explains why they do it: it’s like pinball, the reward for winning is you get to play again. The reward for building one machine is the chance to build the next one. That’s the most accurate description of engineering motivation I’ve ever read, and it’s also why bonuses so rarely work the way management thinks they will.

And there’s West’s line about shipping, “Not everything worth doing is worth doing well.” Eagle isn’t elegant. It’s a 32-bit extension of their existing 16-bit architecture, full of compromises to stay compatible, and the team knows it. They ship it anyway, because a good machine that exists beats a perfect one that doesn’t. I’ve had to make that argument in every job I’ve had, usually to engineers, sometimes to myself.

The chapter on chasing an intermittent hardware fault with a logic analyzer is also one of the best descriptions of debugging I’ve read anywhere, and this isn’t a technical book at all. If you’ve ever chased a heisenbug at 2am you’ll recognize every step.

It’s short, it reads like a novel, and nothing in it has dated except the hardware. Read it. And notice where it happens: a basement in a nondescript office park off a highway in Massachusetts. No garages, no Stanford dorm rooms.