
Reflecting on the Soul of a New Machine - janvdberg
http://dtrace.org/blogs/bmc/2019/02/10/reflecting-on-the-soul-of-a-new-machine/
======
packetslave
There's a fantastic comment on the article written by Jessamyn West (Tom's
daughter):

 _I saw this zipping by on Twitter. Heya I’m Tom West’s daughter and I always
pop onto threads about SOANM to bang the drum of good work-life balance as
well. My dad was an amazing man and we got along well, but he was a pretty
distant dad and basically left the raising of my sister and me to my mom who
might have wanted to do something professionally as well._

 _The things he did at work, and his and Kidder’s ability to talk about them,
were quite interesting and have lessons that can be relevant in many different
timelines and lifestyles. But you know, I wound up moving to Vermont and
helping people use technology to solve problems in their lives. You need all
the things–technology, an understanding of people, and a life–and my dad
possibly only had two of those at any one time. Thanks for writing this._

~~~
greglindahl
Wow, I've worked with her professionally, and had no idea she was connected to
a book I read and loved when I was young. Always interesting to hear more of
the story around a company and a family.

------
deanmoriarty
I struggled with this a few times: “When a person signed up to do a job for
him, he would in turn trust that person to accomplish it; he wouldn’t break it
down into little pieces and make the task small, easy and dull.”

I’m not particularly talented, far from it actually, but many times I’ve
worked in teams with non-junior people who were tasked to do some portion of a
project, and simply delivered garbage: a terribly over engineered solution in
a component where over engineering was actually very dangerous (e.g. doing
distributed systems using several small bespoke moving parts rather than a
single solid leader election mechanism, or even better getting away with
something leaderless and more elegantly stateless, to give a recent example).

In those occurrences, I inevitably “broke it down to pieces” by keeping
pointing out all the exact scenarios where the code delivered would fail,
until the other person really had to finally move to a solution much more
similar to the one I had in mind (much much simpler). Sometimes this required
an embarrassing feedback loop of 10+ round trips, where every time I’d just
look at the newly delivered code say “this doesn’t work in a X scenario”. And
I was not in a better position from a knowledge perspective, we were
essentially peers.

I felt like a prick and definitely felt resentment from the other party
(especially since code reviews are public), but at the same time, how could I
have acted differently? The end result was really orders of magnitude better,
more robust and smaller.

~~~
tonyarkles
I wish I knew the answer to this, but I don’t. The closest I’ve come to
succeeding at this is to have a reputation as a “breaker”. This really started
in undergrad algorithms; I wasn’t great at finding solutions, but I had a
knack for finding edge cases to break solutions others had come up with.
Sometimes it just needed a tweak to work, sometimes it was “throw it all away
and start over”. For the few times I’ve done regular office-style work over
the years, that’s come in handy. I feel like a dick a too, but I try to be
really gentle and end up with people showing up on their own to “run something
by me” before building it out. Saves everyone frustration!

There have been colleagues though who do exactly what you’ve described. That
brutally painful loop of breaking pieces of an overly complicated solution
over and over. My unfortunate confession is that I usually end up giving up
and let them fail on their own. I’m always willing to help, but if someone
doesn’t want help, I won’t spend much energy forcing it on them.

~~~
bookofjoe
Yes! Finally, a word — "breaker" — for my greatest talent, which I still
haven't found a way to monetize in my 70 years and 8 months on the planet. I
can unerringly and quickly find the FAIL point in most
devices/methods/ideas/setups/systems/websites etc. in a savant-like fashion.
Perhaps in the future I'll find someone who will pay me for my quirky skill.

~~~
ThrowawayR2
Software QA. Not particularly prestigious but the pay is passable, more so if
you can code well enough to automate tests or dig into the codebase to isolate
the bug.

~~~
bookofjoe
Alas, I cannot code at all.

------
tasty_freeze
I read the book when it came out and I loved it.

A few years later, in 1986 to be specific, I started a job at an OCR company.
My cube was directly across from the office of Carl Alsing, the guy who
managed "the microkids". I didn't put two and two together at first. Alsing
was one of the people who interviewed me for the job, and I got to know him a
little bit for a couple months before someone told me about the book
connection.

So I went to the library, got the book out, and read it again. When Kidder got
to the part where he introduces Alsing, it was amazing. In a paragraph he
captured details about Alsing that I hadn't even realized myself (eg, his
personality projects the image of a smaller man, though he was actually
decently tall).

The other thing he got right was Alsing wasn't much for schedules and tended
to work on things that interested him instead.

Anyway, having verified that Kidder had indeed captured a lot of truth about
Alsing, it gave me trust that the rest of the book was similarly accurate, and
not just sexed up in the process of storytelling.

------
whyisthewhat
I loved this book as a kid, although once I got into the work force and began
to appreciate the value of a work-life balance and the basically unbrigdeable
gap in incentives between management and labor, I started to look at the
ludicrous demands the company placed on its engineers with a more jaundiced
eye.

My perception of the team leader hero, Tom West, was also permanently altered
by an essay written by his daughter Jessamyn (a quasi famous technologist in
her own right), who described him as basically a depressed alcoholic.

~~~
voltagex_
I'm having trouble finding the essay - can you give me some pointers?

~~~
sdenton4
The essay I remember is this one, which isn't nearly so harsh as what the
patent comment suggests (but is a lovely read, with good advice):
[https://medium.com/message/deathhacks-b767903b7c15](https://medium.com/message/deathhacks-b767903b7c15)

~~~
jacquesm
That is worth posting separately.

------
spudlyo
I've always considered myself lucky that one of first minicomputers I got to
know and love was a DG Eclipse. I had the experience of reading the book in
college and learning the weird, wonderful, and amazing AOS/VS operating system
at the same time.

In the late 1980s I got to learn a ton about an operating system that had
threads (tasks), virtual memory, shared memory, rich filesystem ACLs, symbolic
links, and a bizarre shell language that forced you to do all your looping via
recursion.

I learned how to program in C on that machine, I wrote some of my first
assembly on that machine, and I spent hours pouring over thick black three-
ring binders filled with manuals on OS usage, system calls, and the hardware
architecture.

Friends and I competed to learn arcane details on how the system worked. My
main claim to fame was I figured out how to share memory between unrelated
processes, and how to use the atomic-test-and-set instruction to safely
synchronize access to it.

One time while we were studying the virtual memory system, a friend wrote a
program to see what would happen if you allocated the entire 4G address space
of virtual memory and then randomly touched different pages of it.
Predictably, the storm of page faults ground the machine to a standstill,
causing our lazy sysadmin to have to put down his his copy of Datamation and
address the gathering throng outside his door.

I have this recurring dream that I'm back at college for some event, and I
wander into the Computer Center and look around. In the very back, there is a
dusty 'Dasher' D210 terminal next to some stacked up old furniture -- plugged
in and emitting a dim green glow. It's hooked up to our MV/10000 Eclipse,
which I imagine is still in the basement of the Library Building humming along
after all these years. I try to log in, but I can't remember any of my old
accounts and passwords.

~~~
chiph
We had a MV/8000 at college, and it was a really nice machine. We had
compilers for Pascal, C, COBOL, and oddly enough, Ada. You could cross-link
these languages, so you'd have a front end written in COBOL that would make
use of a Pascal back end. And the bindings just worked.

You knew when an Ada compilation job had been started because the other
terminals would start getting sluggish...

------
abraae
I took a valuable lesson from the book that has served me well over the years.

At one point the CEO injects a critical piece of wisdom by telling the
engineers they are not allowed to use a mode switch to preserve backwards
compatibility.

In any system, the presence of mode switches often points to where things will
go wrong. If a system has two modes, then inevitably, one of them will be more
unloved, untested, under documented and unreliable than the other.

~~~
notacoward
OTOH, in the context of a distributed system that has to be upgraded live and
the deployment of new code has to be carefully staged across hours or days
(e.g. a storage cluster with thousands of machines), such mode switches can be
absolutely essential. The process can look something like this.

* Roll out the code with support for a new feature

* Flip the mode switch on a few nodes to _use_ the new feature

* Wait a while, watch for anomalies

* Enable the new feature on more nodes, until it's on all

* Disable support for the old feature (another mode switch)

* Eventually, roll out new code with the old feature entirely removed

It's not quite a whole-system mode switch as in SoaNM, but that's kind of the
point. In a distributed system actions do not affect the whole system all at
once, so different rules apply.

~~~
jacquesm
A feature switch is not a mode switch. A feature switch in the 'on' position
just gives. A mode switch gives and takes away in the 'on' position.

------
PhantomGremlin
My favorite takeaway from the book was the concept of pinball: if you win, you
get to play again.

Also the Mushroom Theory of Management. Easy to encounter that firsthand.
"keeping them in the dark, feeding them shit, and watch them grow."

[https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine#Them...](https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine#Themes)

------
skybrian
For an interesting glimpse of a different trade, I recommend _House_ , also by
Tracy Kidder.

------
segmondy
I just read the book not too long ago myself. Thoroughly enjoyed it. The book
that got me going was Hackers by Steven Levy which I've ready easily 20x. This
book is just as good. I also think reading this much later in life gave me a
fine appreciation as someone in Management of developers, politics, dealing
with teams, trusts, motivations, etc. It's actually stunning how relevant the
story still applies even tho it was written before most of us were born.

------
cafard
I read bits from the book in The Atlantic (I think) before I ever saw an MV.
Some years later, my wife read the book for a class in her MBA program, and I
read the whole thing.

A couple of points struck me then that may be of interest to the HN
readership.

First, the instruction set originally proposed by the architect was very VAX-
like. It would probably have been great for those writing in assembler. But
the end was approaching VAX-like instruction sets.

Second, retaining the old Nova/Eclipse instruction set meant that one kept
three general-purpose registers (well, sort of general-purpose: by convention,
I think the stack pointer was in AC3). One also had no register-relative byte
addressing.

I liked the Novas and Eclipses, and learned a lot working on them. But the
RISC-based UNIX machines took over from the minicomputers pretty quickly.

[Edit: I don't think I've used an MV since about 1995--take any remarks with a
grain of salt.]

------
sureaboutthis
It was fun reading the book as I was embedded in all the blue, black and red
of wire wrapping my own boards for a mini-computer I designed and built for a
company back then. There were times when I wondered if I was doing the right
thing and to see that others did the same as I made me feel much better.

------
mirrorlake
There is an interview with a few of the engineers on ScienceFriday's YouTube
channel. Definitely worth checking out if you've read the book recently.

[https://www.youtube.com/watch?v=0wq3ucqnaSk](https://www.youtube.com/watch?v=0wq3ucqnaSk)

------
2sk21
I read this book when I was in college and it had a profound impact on me - it
was one of the primary motivators for me to get into computer science. Then
when I came to the US for grad school in the mid 1980s, I got a programming
job on campus in a lab and was shown around the computer room by my
supervisor. And there I came face to face with the DG MV8000 and gave me a
tremendous thrill. For the next couple of years when I worked on that machine
(learning C among other things), I used to imagine the scenes from the book.

------
tosh
related: Jessie Frazelle just published this
[https://blog.jessfraz.com/post/new-golden-age-of-building-
wi...](https://blog.jessfraz.com/post/new-golden-age-of-building-with-soul/)

------
microtherion
WIRED had a rather nice retrospective on this book in 2000:
[https://www.wired.com/2000/12/soul/](https://www.wired.com/2000/12/soul/)

------
EngineerBetter
Dang, and there was me hoping for a write-up of the Fear Factory album.

------
Upvoter33
Not everything worth doing is worth doing well -- Tom West

