This book makes the argument for engineers to have the ability to process, interpret, and design things "in their head" or by using sketches, graphics, back of the envelope squiggles, and so forth. Less emphasis should be made on obtaining high-precision numerical answers.

I don't disagree with the premise of this book, but found the first half to be incredibly dry and draggy. Reading a discussion of 500 years of civil and mechanical engineering drawings was boring. Not to mention, the emphasis on machinery and military fortifications alienates all of the people who don't care about that (namely, the same people we have difficulties getting and keeping in the STEM pipeline). And even for a book written 30 years ago, COME ON WITH THE MALE PRONOUNS ALREADY!

I am the absolute worst at understanding how mechanical things work unless I can actually physically interact with them. Then again, I have no background in mechanical and civil engineering because those fields never interested me in the slightest. Is that a problem with early engineering education that spent hours and hours on linear algebra in my statics class while in my intro to EE class I got to build circuits? Maybe. Does it mean that I'm a bad engineer? Definitely not. But let's also remember that women in general are not given this background at all, and assuming that a "good engineer" is somebody who can understand how an engine works in their mind is a horrible assumption that has kept women and other folks out of the field for a very long time. So I think we need to change the idea of what we mean when we say that engineers should have a good intuition for our practice. That should not be limited to mechanical models. I found that to be a very large drawback to this book, the limitation to the mechanical and the ignoring of literally everything else.

However, I completely agree with the author's statements on highly educated engineers being incapable of solving practical problems. My undergrad (which started 10 years after this book was published, just for some temporal context) had exactly two design-based classes, but never taught me *how* to design, and never scaffolded my learning. That means that I didn't have any "easy" design projects at which to safely fail before getting thrown into a huge project that obviously didn't have any relevance with the highly numerical approaches I'd been learning all along the way. My lab classes were fun, but never made the connection between the practical and the theoretical in a very profound way. So I came out of undergrad feeling like I had no useful practical skills. By the time I got my PhD it was even worse. I mean, I could align microscopes and laser setups worth tens of thousands of dollars and work in multi-million dollar cleanrooms. But I didn't know how to solder or build anything.

That all changed when I became a professor, and now I try to impart to my students the necessity of being able to do things. I teach intensive lab-based classes and have students design and build a project. I don't care if it works, but I want them to design it and do the best they can to put it together, and learn from the process. I want them to develop an intuitive sense for how to troubleshoot and debug, as those skills will do them well forever. I want them to develop the sense that they can do everything, even if they have no idea (right now) how to do anything.

Also, I see my students routinely rely on absurd amounts of precisions in their answers. When I ask for a resistor value and my students write down "313.5123581 Ohms," I ask them to go find that resistor in our parts cabinet. I totally agree with the author's take on the feelings of security and superiority that precision in numbers gives students, that will obviously follow those students along with them into their careers. (It also gave me an idea for a project I can do with my students to hopefully help get them to think critically about assumptions about accuracy and precision.)

The end of the book was similarly interesting with its focus on system errors, but I think it seemed out of place. I'm really interested in complex systems and the errors that occur due to the intersection of so many moving parts (literal or otherwise). But the author's assertion that this is due to the fact that we use computer aided design now (or at least, in the 80s/90s) is somewhat disingenuous, when the issue is that the systems we design now are just SO MUCH MORE COMPLEX than anything we would have been designing in the 1930s/1940s/etc. While I didn't disagree with the argument, it came across as a cranky old guy complaining about computers.

If the book had just been a shorter essay about the need for understanding the assumptions we make when we get an answer, and how we can build the skills to get a better intuitive feel for our practice (and without all the emphasis on the alienating examples like fortresses and pumps), then this book would have been pretty great. ( )

A good book on engineering design from the aspect of who engineers are. ( )