Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflecting on the Soul of a New Machine

dtrace.org

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Reflecting on the Soul of a New Machine

#21

Post by sowbug »

deanmoriarty wrote: post #3

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 terribl…

Giving feedback doesn't necessitate micromanagement (which I'm using as a synonym for demanding a particular "how" in addition to an assignment of "what"). Would your experience have been better if you'd given the same high-level feedback as what you've shared with us? For example: "Hey, Non-Junior Person, your approach appears to be overengineered. For this application, overengineering isn't a matter of taste; it's a matter of safety. Please come up with a simpler approach."

Re: Reflecting on the Soul of a New Machine

#23

Post by 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.

Re: Reflecting on the Soul of a New Machine

#24

Post by notacoward »

deanmoriarty wrote: post #3

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 terribl…

I can't quite decide if this sounds great or awful. If code hasn't been adequately verified and/or tested, helping someone address those omissions (which would require fixing the bugs they make manifest) would be great. OTOH, merely "pointing out" or saying "this doesn't work" sounds not so great, and "similar to the one I had in mind" rings a huge NIH alarm bell. Instead of wondering whether you were being a prick, I'd highly recommend asking your other peers for suggestions on making the process less adversarial.

Re: Reflecting on the Soul of a New Machine

#25

Post by agumonkey »

deanmoriarty wrote: post #3

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 terribl…

in these situations I'd hope for people to naturally gather around positive ~negotiations. Open and constructive sharing of ideas.

Re: Reflecting on the Soul of a New Machine

#26

Post by notacoward »

beachy wrote: post #14

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, unde…

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.

Re: Reflecting on the Soul of a New Machine

#28

Post by mirceal »

deanmoriarty wrote: post #3

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 terribl…

over-engineering is real and is slowing things to a grind around you everyday.

my conclusion is that people don’t really like simple things and they believe that complex=good and it’s a sign of how good/smart you are. so people are suckers for complexity. nobody is going to receive a medal or a promotion for well written and simple code that “just works”. you won’t know it’s there.

now, the reaction you’re describing comes from the “i’ve seem some shit” syndrome where not only you can see the layers upon layers of unnecessary crud but you can also see how it’s going to break in the future. it’s terrifying.

Re: Reflecting on the Soul of a New Machine

#29

Post by 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.

Re: Reflecting on the Soul of a New Machine

#30

Post by chiph »

spudlyo wrote: post #8

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 biza…

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...

Post reply on HN