My favorite little bit of content about SOANM, and Tracy, is attached to this 2013 blog post.
https://tispaquin.blogspot.com/2010/12/1982-interview-with-t...
It's a 1983 report from The Computer Museum (Inside "The Soul of a New Machine" Tracy Kidder and Tom West) which contains the partial transcript of an event that Tracy and Tom did together, that I don't think they did again. When Tracy was asked what he was up to and if he was sick of computers, he said
"I'm digging out from under. I'm writing some articles about atmospheric research. To be honest, I'm a little tired of my book. I put it on my shelf and won't read it again for years. I think I know what's wrong with it. In some sense, writing a book is like building a computer. There are rewards but one of the main ones is that Sisyphean one that if you do one you get to do another. So, I have an opportunity now to write a better one." And he did, he wrote so many books that were, if not better, at least just as good.
So I reread the book and my esteem for Kidder's writing went up even more. In the parts of the book where he described Alsing's appearance and demeanor were spot on and captured essential things about Alsing without using a lot of words.
One of the things I recall is Kidder said something like, "Alsing is a tall man, but his mild demeanor and hunched posture presents a much less imposing figure." Sure enough, that is exactly the experience I had with Carl.
(They also had an engineering executive who had been a computer engineer from a major CPU company. In one engineering reporting meeting, when a team mentioned they needed to do something with a particular facility of the off-the-shelf CPU, the executive volunteered that he could help with that, since he designed it. Everyone laughed.)
Hardware companies are a mixed blessing for us software people, but I wonder whether hardware engineers are more likely to keep it real (old-school high-powered engineer style) than software people?
Moutains Beyond Mountains[1], another book by Kidder, is even more compelling to me. It's a fascinating story of Paul Farmer, who dedicated his life to fighting infectious disease, especially in Haiti.
[1] https://en.wikipedia.org/wiki/Mountains_Beyond_Mountains
(Farmer himself died a few years ago, at only 62, of a sudden heart attack in his sleep, but he seems to have put in about 100 lifetimes worth of work. One wonders if his legendary overwork contributed to an early death.)
Farmer grew up incredibly poor, got into Duke and Harvard, had opportunities to make incredible money and traded it for a life of providing medical care to the third world on a shoestring budget while schooling organizations like the WHO on how to provide care along the way.
Truly one of one.
His whole catalogue is fantastic really. Definitely a favourite author of mine.
His one quote [1] remained in my imagination, and inspired me to learn management. Context: Tom West and his team have acquired a VAX system from DEC, and are reverse-engineering it to see how it is setup.
"...Looking into the VAX, [Tom] West felt he saw the diagram of DEC's corporate organization. He found the VAX too complicated. He did not like, for instance, the system by which various parts of the machine communicated with each other; for his taste, there was too much protocol involved. The machine expressed DEC's cautious, bureaucratic style. [West was pleased with this idea.]..."
It inspired me to become a better manager precisely because I was tearing down bureaucracies in my own work.
Every now and then when I mull over product failures (or successes), I see the product architectures reflect the organizational messes they are born in.
RIP Tracy Kidder.
[1] https://www.scribd.com/document/882178766/Tracy-Kidder-Flyin...
Applies both to software as well as hardware.
Eventually one of the engineers broke. He left and never came back. He left a note on his desk reading "I am going to live on a farm in Vermont, and I will no longer deal with any unit of time shorter than a season."
At age 21 (and accomplished, since I'd started working in my teens), I mentioned the book to my girlfriend, who was getting into software. As a serious English major, she immediately went and closely read the whole thing. I stupidly hadn't realized that of course she was going to that. And I'd neglected to mention that parts of it are a frustrating slog, as the reader suffers along with the characters/subjects. As a reader with empathy, she came out of the book fatigued and somber.
(But she'd said "an artist needs a craft", so she stuck with the field, was very successful, retired early, and has a second/third career doing something brilliant but much less lucrative.)
Despite learnings from the book and experience, I've had a few such unpleasant project slogs. But more projects that I was able to help make non-unpleasant, because I could anticipate and avert some of the problems.
I think the book probably contributed to my tendency to commit seriously to projects. That's been good and bad. It's good, in that you can learn and do things that you otherwise couldn't. It's bad in that it takes you longer to understand that other people are not you, and the ways that they aren't as committed to the project.
Many/most people are about putting in their hours with some standard of professionalism, such as satisfying whatever metrics (e.g., Jira tickets, sprint tasks, KPIs, OKRs, bonus/promotion criteria) they're told are their job. Those, you can work with, once you know that's their mode. You can also try to improve the company incentives that determine outcomes.
(But occasionally you'll encounter people who are misaligned with project/team/company success in a way you can't find common ground with. You have to recognize that hopelessly toxic situation before it's too late, and get them out of the way of the team of aligned people.)
This book of Tracy Kidder told the story of some early computer industry engineers doing something great, through brains, effort, and perseverance -- and that's a great accomplishment for a book. But an additional accomplishment I think was that a lot of us kids who read it then signed up to "play pinball", with an informed idea of what we were sometimes getting ourselves into, and we signed up anyway.
I ended up keeping the book for ~25 years and only at the time of his 50th birthday a few years ago I reckoned we're old enough now. I read the book once more and shipped it to him, literally halfway across the world. Great memories. Thank you for your work, Mr. Kidder.
But I can't help but think that the book helped normalize death-marches in the industry. I'm still recommending it to colleagues, but with the caveat that we are not in a "do or die" situation, so go home and get some good sleep.
When I re-read the book ten or fifteen years later as an adult facing burnout, I was awed again – by the human cost of the project. Grim stuff.
Fantastic book, but it bothers me that technologists who talk about it almost universally want to talk about the product, and often don't even notice how well the book depicts a real meat grinder of a process. Kidder was not a technologist, and I think that gave him a wonderful ability to really see everything that was happening around him, and to not simply fixate on the computer they were building.
Fun fact: Data General was purchased by EMC, which used the name until 2012.
I kept a copy of the book at hand and read it from time to time whenever I need a boost of morale. It is very inspiring -- although the reality was probably more gruesome and less glorious. I keep roleplaying the roles in the books in my side projects, to a certain degree. Fake it until make it, they said so.
I was late to the party and only read “The Soul of a New Machine” in 2024. It's a great book I think anyone involved in engineering of any kind should give it a read.
It's an especially impressive feat of writing given that it remains accessible and interesting even to people outside of the field. It's a testament to the amount of time he spent essentially embedded with the people at Data General learning about their work and about who they were.
The hardware was pretty solid, although I'm not sure anyone got around to doing custom microcode that was a selling point. The operating system (AOS/VS, was it?) was OK, but had some edge cases - I remember the filesystem had ACLs (access control lists), but you could create files owned by non-existent users (promptly used for a prank).
Thanks for the tale, it made a dent.
RIP Mr. Kidder.
Black bar?
RIP Tracy Kidder -- and thank you for giving us all permission to feel passion for the machine.
[0] https://speakerdeck.com/bcantrill/oral-tradition-in-software...
[1] https://bcantrill.dtrace.org/2019/02/10/reflecting-on-the-so...
[2] https://bcantrill.dtrace.org/2019/12/02/the-soul-of-a-new-co...
