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

11–20 of 50 posts

Re: Reflecting on the Soul of a New Machine

#11

Post by deanmoriarty »

korijn wrote: post #10
tonyarkles wrote: post #6

Earlier quoted context omitted.

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…

IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.

In my experience, it doesn’t work that way at all.

What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management.

On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y.

Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic.

I’ve seen this script dozens of time.

Re: Reflecting on the Soul of a New Machine

#12

Post by voltagex_ »

whyisthewhat wrote: post #2

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

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

Re: Reflecting on the Soul of a New Machine

#13

Post by blihp »

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've only seen it work when there's a combination of competence and ownership. i.e. someone from above can't just say 'this is yours, figure it out', the other party has to be able to do it and accept the ownership of it. Even when they can and do, there will inevitably be things they get wrong and/or miss but when those are pointed out they, assuming they've accepted ownership, will understand without being asked that it is for them to correct. If you try do it before someone is able or willing, it can turn into a train wreck. Also, I've found it much harder to do in larger organizations for a variety of reasons.

Re: Reflecting on the Soul of a New Machine

#14

Post by beachy »

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.

Re: Reflecting on the Soul of a New Machine

#15

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

Re: Reflecting on the Soul of a New Machine

#16

Post by PhantomGremlin »

korijn wrote: post #10
tonyarkles wrote: post #6

Earlier quoted context omitted.

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…

IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.

That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about.

Circa 1980, around the time of the events in the book, the time delays involved in making design changes to boards built from MSI building blocks were bad enough. Physical wire mods to a board took hours or days. New boards could be made in weeks or months. There was also some flexibility because parts of that design used PALs, which were easily reprogrammed.

But in today's world the time cost of a re-spin of a CPU or a highly integrated SOC chip is huge. Months for simple changes, years for complete re-designs. Just look at the time estimates for hardware changes to x86 chips to mitigate Spectre and Meltdown. Some months for new microcode; many years for new silicon.

Nevertheless, it's perhaps easier to let things happen and afterward think "I told you so". Because, unfortunately at most companies, if you try to impart those lessons earlier in the process, e.g. at design reviews, you quickly get the reputation of not being a "team player". Sounds crazy, but that's simple human nature.

Re: Reflecting on the Soul of a New Machine

#17

Post by silveroriole »

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…

When the coder is a peer and you’re not their mentor, manager, or lead, I normally keep code review comments to suggestions or questions - “What happens here in X scenario? Maybe we should refactor this part out into a stateless microservice?” That avoids the resentment and makes you look less like a control freak, but still shows your competency/foresight. If they choose not to take your advice, too bad for them, but I try to make sure they end up personally fixing the inevitable problems and hopefully learning from it.

Other than that I haven’t found any great solution, but I have found it stressful and counter-productive to try and do EVERYONE’S thinking for them. They do not learn in that case, they just continue to outsource their thinking to you.

e: also 10+ rounds is excessive for a peer review imo, after 2 or 3 I’d be having a higher level design chat with their lead/manager.

Re: Reflecting on the Soul of a New Machine

#18

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

Re: Reflecting on the Soul of a New Machine

#19

Post by sdenton4 »

voltagex_ wrote: post #12
whyisthewhat wrote: post #2

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

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

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

Re: Reflecting on the Soul of a New Machine

#20

Post by EliRivers »

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…

The quote you quoted says "signed up to do a job for him", but then what you describe is people being "tasked to do some portion of a project".

Is there a difference in that? If I sign up to do a job, that's quite different to having something assigned to me. Things I sign up for are things I have chosen, based on my abilities and enthusiasms; things that are assigned to me.. well, not so much.

Post reply on HN