related: Jessie Frazelle just published this https://blog.jessfraz.com/post/new-golden-age-of-building-wi...
Reflecting on the Soul of a New Machine
31–40 of 50 posts
Re: Reflecting on the Soul of a New Machine
#32There 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.
Re: Reflecting on the Soul of a New Machine
#33I 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.
Re: Reflecting on the Soul of a New Machine
#34I 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 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…
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.
Re: Reflecting on the Soul of a New Machine
#35I 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.
That was my observation as well. I find the quality of work goes up dramatically when people are invested personally in the success of their part of it. "Signing up", to me, is about committing to that sort of investment, and it's the signal I look for to know if a team is going to be healthy. Not having that signal is a two-way street, though -- sometimes the answer is to restructure the work overall so that the pieces align better with what team members will sign up for.
Re: Reflecting on the Soul of a New Machine
#36Earlier 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…
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.
[deleted]
Re: Reflecting on the Soul of a New Machine
#37I 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 inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, ... I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public)
There's the problem, right there. Using a code review to expose a design flaw.
I worked at my first startup starting in 1988, not long after SOANM came out. Most of the engineers at this company read the book. I was struck by the similarity between the situations and dynamics described in the book, and what I was observing first-hand.
Our approach to engineering was academic in nature. This was remarkable because there was only one PhD in the bunch -- me, the most junior person -- and everyone but me had a spectacular track record of designing, building and delivering innovative products.
We started with whiteboard discussions. These would go on for hours at a time, across multiple days. When we had the outlines of a workable idea, someone would go and write a design document. And that got reviewed extensively, over a few days. The "breaker" sorts of analyses got done at this point.
So by the time we started implementing, we knew we had a very solid design. From that point on, bugs were just bugs. They weren't these initial cracks that revealed a rotten foundation.
I thought that this approach worked incredibly well. And I was dismayed to observe that it wasn't practiced elsewhere. I did try to institute this approach a few times, but it doesn't really take hold unless you have other senior people who want to adopt it. And at my last startup, we had smart but young and inexperienced developers who were bought into Agile, and code reviews substituting for design reviews. The predictable (and predicted) hilarity ensued.
Re: Reflecting on the Soul of a New Machine
#38I 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 inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, ... I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public) There's the problem, right there. Using a code review to expose a design flaw. I worked at my first startup starting in 1988, not long after SOANM came out. Most of the engine…
Yeah, these days what you are describing is simply utopy, at least according to my experience spanning a single decade across two startups and two large companies.
Engineers, once they are hired and passed the interview, are mostly seen as a commodity, in the sense that, in the eyes of management, every non-junior engineer should exactly be able to come up with the correct idea (modulo a short phase of code review, just in case), so the output they produce can just be as equally produced by a peer (just like a commodity): in that world view, design meetings spanning multiple days don't do much, and they just make you lose time against the current jira sprint.
I would love to work in a place where management understood that collective intelligence is almost always superior than the initiative of a single person, and thus it's very important to have a design phase where as many engineers as possible are involved.
Every single time I had to lead a significant project, I always spent so much time involving as many people as I could find to discuss the idea, constantly self doubting my ideas. Incidentally, very few significant bugs have occurred when the project was delivered, in contrast with the example I was quoting, where the thing was developed completely hermetically by another non-junior engineer, who failed to account for many non-to-rare corner cases.
Re: Reflecting on the Soul of a New Machine
#39Earlier quoted context omitted.
> I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, ... I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public) There's the problem, right there. Using a code review to expose a design flaw. I worked at my first startup starting in 1988, not long after SOANM came out. Most of the engine…
Yeah, these days what you are describing is simply utopy, at least according to my experience spanning a single decade across two startups and two large companies. Engineers, once they are hired and passed the interview, are mostly seen as a commodity, in the sense that, in the eyes of management, every non-junior engineer should exactly be able to come up with the correct idea (modulo a short phase of code review, j…
Effective agile teams practice swarming by minimizing the work in progress "inventory" and focusing all team members on a very small number of stories at a time. You can sell it to management in terms of adopting agile best practices and reducing the cost of delay.
https://www.agilealliance.org/resources/experience-reports/s...
Re: Reflecting on the Soul of a New Machine
#40Earlier 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.
Only lazy, sloppy developers fail by repeating the same mistakes as others. Unless they're working on something truly novel (unlikely) there are books and articles out there which explain the problems to avoid.