Shop Class as Soul Craft review

I’ve been seeing Shop Class as Soulcraft around for a while now. One of the local hackerspaces has a copy, Venkat Rao over at Ribbon Farm put the book on his reading list, and it showed up on the shelves of my local technical bookstore. I put off reading it because I was worried about it being too polemical and reactionary, but with so many people recommending it, I had to give it a chance.

The book, by Matthew Crawford, focuses on how shop class and working with your hands is both economically and morally worthwhile. The author works as a motorcycle mechanic, but has a PhD in philosophy and got his bachelor’s degree in physics. I tend to have a real fascination with people who’ve seen what’s supposed to be good and chosen something else, so just from his background I already like the author. The book itself seemed overly verbose and grandiose. This might just be because the author has a PhD in philosophy, but I think there’s some attempt to be as respectable as possible while praising blue collar work above white collar work. Despite the verbosity, I liked the book.

There was a lot of ground covered in the book, but it seemed to have three main points. Crawford argues that “Blue Collar” work, and any work that involves actually making something physical, is more emotionally fulfilling and economically secure than white collar work. He also makes the argument that making things is a very different way of knowing than simply doing theoretical work. Shop Class as Soulcraft also had a long autobiographical portion, showing how and why Crawford had gotten involved with the mechanical arts.

Work in general is hard and most people wouldn’t volunteer to do it. That’s why they pay you for it. Crawford acknowledges this, but then goes on to say that work that involves some concrete and external metric (such as all work that involves making something) is more fulfilling. It shelters the employee from some of the capriciousness of management. Both the employee and the manager can look at the thing that is built and tell if it meets its criteria. Knowledge workers have no such thing to fall back on, and are thus more subject to the whim of management.

Not only that, the pressure over the last hundred years to put all manual labor in an assembly line seems to have reached everywhere that it could. Any manual fields that have avoided an assembly line are unlikely to be transformed. Repair work, construction, and installation all demand that a person be at a specific place, so those jobs are more or less immune to outsourcing. White collar knowledge work does not have either of these safety nets. Programming, human resources, and similar knowledge work have all begun to face outsourcing and assembly-lining. White collar jobs are no longer as secure or well paying.

Knowledge through doing is something that I’ve been considering more and more lately. I’ve been continually impressed with how much some of my friends know. Those friends of mine who are consistently making things, hacking, or working on projects seem to know quite a bit more about the world. Crawford argues that this is because it is only through making things that we really run into the physical reality of our universe. Only by trying to do something do we find out what’s possible.

One example the book gives of the differences between knowledge through doing and theoretical knowledge is that of shoelaces. According to knot theory, it’s always possible to untie a shoelace just by pulling on one end. It doesn’t matter if it’s double knotted or tied in some crazy way. As anyone who’s hiked up a mountain and come home with wet, muddy shoelaces can attest, this is not true. A mathematically ideal shoelace may have this untie-able property, but in the real world it depends on the quality of the shoelace.

Theoretical knowledge is useful, and Crawford is quick to point out that it is worthwhile, but all problems occur in the real world. Theoretical knowledge can inspire solutions, and even lead to very effective solutions, but you have to be careful that the theory doesn’t assume ideal shoelaces. Also, those without a theoretical background are still capable of doing very intense intellectual work very well, especially if they have a deep well of experience to draw upon.

I found the autobiographical portions of the book very interesting. The author seems to have had an exciting life in many ways, much of it filled with wood working and car or motorcycle repair. I enjoyed reading about his life, but some of it seemed not so much to support his point as to talk about how he arrived at his point.

My main criticism of the book is that it tends to be light on many details. For example, one chapter deals with the construction of the blue collar/white collar separation. Crawford makes the point that this was done explicitly by scientific management devotees. He offers some support, but doesn’t go very in depth into the topic. I suppose that I have to accept that a polemic book isn’t meant to be a history book, but I think Shop Class as Soulcraft could have used more detailed analysis throughout.

Overall I’d say this was a good book. It was a fast read; I got through it in about two days. Reading the book did a lot to organize my own thoughts on work and making things. I don’t think I learned a lot of new things from the book, but I did enjoy it. I give it 5/7.

In praise of requirement shift

One of the complaints that I’ve heard most often from engineers in various industries is about the requirements shift that often happens midway through a project. It’s a common refrain: “I had almost finished the project, and then my boss told me to do everything in a totally different way. Why can’t they just make up their minds?”

I’ve only ever worked at small companies where the design decisions were fairly transparent. With only two levels between me and the CEO, it was always pretty obvious why any change was being made. In general I haven’t had to deal with this issue very much in my career, but up to now I’ve been sympathetic to those people who have. A recent project that I worked on gave me some insight into requirement shift from a manager’s perspective, and I now have a lot more respect for projects that experience a lot of shift and upheaval.

A few weeks ago I decided to build myself a frisbot. My idea was to mount some photo-sensors a two wheeled chassis (each wheel would be a frisbee, hence “frisbot”). The bot would then be able to follow a light around. I had a good idea of how I wanted to design the electronics (finally using that MSP430 launchpad I got a while ago), but I wasn’t sure how I wanted to build the chassis. I was thinking a simple plank of wood with the various components mounted to it, but I hadn’t thought much farther than that. I convinced my friend Jared, who has an irrepressible drafting habit, to help me out with the mechanical design.

The two of us sat down and I showed him some videos of other frisbots, and showed him the different electrical components that had to fit on the chassis and we talked a bit about the design. Then we split up and got to work, I wrestled with the MSP430 DAC and he started drafting out the chassis design. Since I hadn’t really done much to spec out the chassis, Jared started asking a few questions about the chassis.

Him: How do you want the motors attached? Can we just mount them on wooden plates perpendicular to the base?

Me: Sure that works. Oh, but can you make them easy to remove so that I can replace the motors later if I want? And add some space to allow bigger motors in the future?

Later

Jared: Ok, the motors plates are done. And you were going to put the dev board here? (points to his design)

Me: Ya, that’s what I was thinking. Oh, wait! I might want to use a different microcontroller later, can you make the space for it larger?

We went through a few rounds of questions like this. He would ask for clarification, and I’d suddenly realize that we could do something slightly differently and make for a better or more flexible design. Admittedly, if I’d spec’d the thing out beforehand this probably would have gone a lot more smoothly. Jared, nice guy that he is, didn’t punch me in the face even after I asked him to change things for the fourth time.

The main point of this story is that the reason for requirement shift is because you don’t know everything you need to do until you’re actually working on it. That’s when a lot of questions get answered. Even if I had written down a full specification for the chassis beforehand, some of Jared’s questions spurred me to think of things that I wouldn’t have even considered beforehand, like adding a crossbrace to the motor plate. The act of making it changed what I thought was best and informed a lot of the design decisions.

Generalizing from this one experience, it seems that requirement shift on a project means you’re doing something new. If you’ve done it before, you know how to do it and don’t have to worry about changing the design halfway through. But if you’ve done it before, then it’s boring. One of the main reasons I like to design and build things is that it’s an educational and inspiring experience. If I only ever build things that I know how to make, then I’m not learning anything or doing interesting things. Even something that was once interesting can become mundane and boring after you’ve done it enough. Having to rethink a design halfway through is actually why I do what I do.

I think one of the main reasons that people complain about requirement shift so much is that in larger companies, the engineers are often isolated from many design decisions. They’re so removed from the design process that they don’t get to experience the wonder of discovery that happens when you realize you have to do something different. It’s not a problem with requirement shift, it’s a problem with openness in the company. This may be why startups don’t have a problem with it. Everyone in the startup gets to experience the fun parts of the design, so they don’t balk when things change.

If you don’t have requirements shift, you’re doing something easy and boring.