Archive

The Dulin Report

Browsable archive from the WordPress export.

Results (86)

Strategic activity mapping for software architects May 25, 2025 On the role of Distinguished Engineer and CTO Mindset Apr 27, 2025 The future is bright Mar 30, 2025 2024 Reflections Dec 31, 2024 My giant follows me wherever I go Sep 20, 2024 The day I became an architect Sep 11, 2024 Are developer jobs truly in decline? Jun 29, 2024 Leadership is About "We," Not "I" Jun 9, 2024 Form follows fiasco Mar 31, 2024 Software Engineering is here to stay Mar 3, 2024 Some thoughts on recent RTO announcements Jun 22, 2023 On Amazon Prime Video’s move to a monolith May 14, 2023 One size does not fit all: neither cloud nor on-prem Apr 10, 2023 Some thoughts on the latest LastPass fiasco Mar 5, 2023 Comparing AWS SQS, SNS, and Kinesis: A Technical Breakdown for Enterprise Developers Feb 11, 2023 Working from home works as well as any distributed team Nov 25, 2022 Why you should question the “database per service” pattern Oct 5, 2022 Stop Shakespearizing Sep 16, 2022 Why don’t they tell you that in the instructions? Aug 31, 2022 Monolithic repository vs a monolith Aug 23, 2022 Automation and coding tools for pet projects on the Apple hardware May 28, 2022 There is no such thing as one grand unified full-stack programming language May 27, 2022 Most terrifying professional artifact May 14, 2022 If you haven’t done it already, get yourself a Raspberry Pi and install Linux on it May 9, 2022 Good idea fairy strikes when you least expect it May 2, 2022 Kitchen table conversations Nov 7, 2021 Application developers like to think their app is the only one Apr 5, 2021 A year of COVID taught us all how to work remotely Feb 10, 2021 What programming language to use for a brand new project? Feb 18, 2020 The religion of JavaScript Nov 26, 2018 Teleportation can corrupt your data Sep 29, 2018 Let’s talk cloud neutrality Sep 17, 2018 What does a Chief Software Architect do? Jun 23, 2018 Nobody wants your app Aug 2, 2017 TypeScript starts where JavaScript leaves off Aug 2, 2017 Singletons in TypeScript Jul 16, 2017 Emails, politics, and common sense Jan 14, 2017 Online grocers have an additional burden to be reliable Jan 5, 2017 Collaborative work in the cloud: what I learned teaching my daughter how to code Dec 10, 2016 Apple’s recent announcements have been underwhelming Oct 29, 2016 What I learned from using Amazon Alexa for a month Sep 7, 2016 Why I switched to Android and Google Project Fi and why should you Aug 28, 2016 Amazon Alexa is eating the retailers alive Jun 22, 2016 In search for the mythical neutrality among top-tier public cloud providers Jun 18, 2016 In Support Of Gary Johnson Jun 13, 2016 Files and folders: apps vs documents May 26, 2016 What can we learn from the last week's salesforce.com outage ? May 15, 2016 Why it makes perfect sense for Dropbox to leave AWS May 7, 2016 JEE in the cloud era: building application servers Apr 22, 2016 Let's stop letting tools get in the way of results Apr 10, 2016 JavaScript as the language of the cloud Feb 20, 2016 LinkedIn needs a reset Feb 13, 2016 In memory of Ed Yourdon Jan 23, 2016 Our civilization has a single point of failure Dec 16, 2015 IT departments must transform in the face of the cloud revolution Nov 9, 2015 I Stand With Ahmed Sep 19, 2015 Setting Up Cross-Region Replication of AWS RDS for PostgreSQL Sep 12, 2015 Top Ten Differences Between ActiveMQ and Amazon SQS Sep 5, 2015 We Live in a Mobile Device Notification Hell Aug 22, 2015 What Every College Computer Science Freshman Should Know Aug 14, 2015 On Maintaining Personal Brand as a Software Engineer Aug 2, 2015 The Three Myths About JavaScript Simplicity Jul 10, 2015 Book Review: "Shop Class As Soulcraft" By Matthew B. Crawford Jul 5, 2015 Attracting STEM Graduates to Traditional Enterprise IT Jul 4, 2015 Your IT Department's Kodak Moment Jun 17, 2015 The longer the chain of responsibility the less likely there is anyone in the hierarchy who can actually accept it Jun 7, 2015 Big Data is not all about Hadoop May 30, 2015 Smart IT Departments Own Their Business API and Take Ownership of Data Governance May 13, 2015 The Clarkson School Class of 2015 Commencement speech May 5, 2015 My Brief Affair With Android Apr 25, 2015 Exploration of the Software Engineering as a Profession Apr 8, 2015 What can Evernote Teach Us About Enterprise App Architecture Apr 2, 2015 Microsoft and Apple Have Everything to Lose if Chromebooks Succeed Mar 31, 2015 Do not apply data science methods without understanding them Mar 25, 2015 On apprenticeship Feb 13, 2015 On Managing Stress, Multitasking and Other New Year's Resolutions Jan 1, 2015 Why I am Tempted to Replace Cassandra With DynamoDB Nov 13, 2014 Software Engineering and Domain Area Expertise Nov 7, 2014 Docker can fundamentally change how you think of server deployments Aug 26, 2014 Wall St. wakes up to underinvestment in OMS Aug 21, 2014 Software Engineers Are Not Doctors Aug 3, 2014 Thanking MIT Scratch Sep 14, 2013 Have computers become too complicated for teaching ? Jan 1, 2013 Thoughts on Wall Street Technology Aug 11, 2012 Scripting News: After X years programming Jun 5, 2012 Java, Linux and UNIX: How much things have progressed Dec 7, 2010

Book Review: "Shop Class As Soulcraft" By Matthew B. Crawford

July 5, 2015

[caption id="attachment_187" align="aligncenter" width="660"]The zen, the art and the motorcycle The zen, the art and the motorcycle[/caption]

Matthew B. Crawford's Shop Class as Soulcraft: An Inquiry Into the Value of Work showed up in my recommended books list on Amazon and it looked intriguing. I've read it, cover to cover, and it turned out to be one of the most influential books of my career.

I didn't go into software engineering because it is a dynamic field or because I enjoy working with eccentric characters. I am a software engineer because all my life the one thing that makes me happy when it comes to work is building something with my hands.

As a kid my favorite toys were erector sets. As I've grown they got replaced with short wave radio kits and finally in my early teens by a computer. Even though “Shop Class as Soul Craft” is about manual work I find it applicable to software engineering. Maintaining a motorcycle requires very similar cognitive skills as maintaining, say, an order management system software.

Crawford questions the value of higher education. We are indoctrinated from early on that we must become knowledge workers. We go to college. We get graduate degrees. Now, consider thousands of MBAs getting entry level administrative jobs that pay far less than, say, entry level computer programmer jobs and you get the point he is getting at.

Why, Crawford poses a question, does a plumber charge you $80/hour while a finance major would be lucky to start at $30/hour ? The difference is that a plumber does something tangible.

In software engineering there are hundreds of books written on the subject of division of labor. “JEE 6 Tutorial” starts off with the description of technologist roles each one dedicated to their compartmentalised effort1. Well, consider this:
Once the cognitive aspects of the job are located in a separate management class, or better yet in a process that, once designed, requires no ongoing judgment or deliberation, skilled workers can be replaced with unskilled workers at a lower rate of pay.

But while the direction of cognitive thought is moving away from the so called knowledge worker, the management is expending a lot of energy on avoiding responsibility for the decision-making aspects of their work:
…one of the principles of contemporary management is to “push details down and pull credit up.” That is, avoid making decisions, because they could damage your career, but then spin cover stories after the fact that interpret positive outcomes to your credit. To this end, upper management deals only with abstractions, not operational details. If things go well: “Finding cross-marketing synergies in the telecommunications and consumer electronics divisions has improved our strategic outlook heading into the fourth quarter.” If things go badly: “Change the Vonage display? That was the kid’s idea. What’s his name, Bapu or something. Jeezus, these immigrants.”

As software engineers many of us consider working on brand new projects a more glorious and satisfying career. Here is the catch – brand new projects require far less cognitive ability and can be labor-divided and outsourced. Maintenance projects, on the other hand, require constant dealing with something not of our own making – much like car mechanics or plumbers jobs. Crawford explains:
Fixing things, whether cars or human bodies, is very different from building things from scratch. The mechanic and the doctor deal with failure every day, even if they are expert, whereas the builder does not. […]

Because the stochastic arts diagnose and fix things that are variable, complex, and not of our own making, and therefore not fully knowable, they require a certain disposition toward the thing you are trying to fix. This disposition is at once cognitive and moral. Getting it right demands that you be attentive in the way of a conversation rather than assertive in the way of a demonstration .7 I believe the mechanical arts have a special significance for our time because they cultivate not creativity, but the less glamorous virtue of attentiveness.[…]

Any discipline that deals with an authoritative, independent reality requires honesty and humility. I believe this is especially so of the stochastic arts that fix things, such as doctoring and wrenching, in which we are not the makers of the things we tend. Similarly, in art that is representational, the artist holds herself responsible to something not of her making. If we fail to respond appropriately to these authoritative realities, we remain [ed: absent minded] idiots.

A prime example from my personal career is learning compiler construction. In college we were taught how to build our own compiler from scratch using lex and yacc. I learned a lot more about compiler construction in graduate school where I had to modify an existing Ada compiler. Likewise, I find that software engineers who always built enterprise systems from scratch and never had to support and maintain an existing one are hardly qualified to do their jobs.

Crawford points out:
We have all had the experience of dealing with a service provider who seems to have been reduced to a script-reading automaton. We have also heard the complaints of employers about not being able to find conscientious workers. Are these two facts perhaps related? There seems to be a vicious circle in which degraded work plays a pedagogical role, forming workers into material that is ill suited for anything but the overdetermined world of careless labor.

Management can't expect workers to be conscientious when their work is reduced to following instructions, processes and procedures. Software engineer can't be conscientious when their work is separated from interaction with business users, sponsors, and analysts. In other words, a good engineer has to eat their own dog food. On the issue of teamwork and office culture, Crawford explains:
we are accustomed to think of the business world as ruled by an amoral bottom-line mentality, but in fact it is impossible to make sense of the office without noticing that it has become a place of moral education, where souls are formed and a particular ideal of what it means to be a good person is urged upon us […] Where there isn’t anything material being produced, objective standards for job performance are hard to come by. What is a manager to do? He is encouraged to direct his attention to the states of minds of workers, and become a sort of therapist. […] one finds an imperative for the manager to care, and to sincerely hold forth to his subordinates the possibility of personal transformation. He is not so much a boss as a life coach. The contemporary office requires the development of a self that is ready for teamwork, rooted in shared habits of flexibility rather than strong individual character. […]

Workers must identify with the corporate culture, and exhibit a high level of “buy-in” to “the mission.” The division between private life and work life is eroded, and accordingly the whole person is at issue in job performance evaluations.

On career vulnerability of managers:
Managers are placed in the middle of an enduring social conflict that once gave rise to street riots but is mostly silent in our times: the antagonism between labor and capital. In this position they are subject to unique hazards. […] Rather, [ed: their] authority is embodied in the persons with whom one has working relationships up and down the hierarchy […]

One’s career depends entirely on these personal relationships, in part because the criteria of evaluation are ambiguous. As a result, managers have to spend a good part of the day “managing what other people think of them.” With a sense of being on probation that never ends, managers feel “constantly vulnerable and anxious, acutely aware of the likelihood at any time of an organizational upheaval which could overturn their plans and possibly damage their careers fatally,” as Craig Calhoun writes in his review of Jackall’s book.9 It is a “prospect of more or less arbitrary disaster.” […]

A good part of the job, then, consists of “a constant interpretation and reinterpretation of events that constructs a reality in which it is difficult to pin blame on anyone, especially oneself,” according to Calhoun. This gives rise to the art of talking in circles. Mutually contradictory statements are made to cohere by sheer forcefulness of presentation, allowing a manager to “stake out a position on every side of an issue. Or one buries what one wants done in a string of vaguely related descriptive sentences that demand textual exegesis.” […]

When a manager’s success is predicated on the manipulation of language, for the sake of avoiding responsibility, reward and blame come untethered from good faith effort. He may then come to think that those beneath him in the food chain also can’t be held responsible in any but arbitrary ways.

One might be tempted to think this is demoralizing for all involved. But we are highly adaptive creatures, and these circumstances generate their own sort of morality, one in which the fixed points of an internal moral compass must give way to a certain sensitivity and nimbleness. Managers may continue to have strong convictions, but they are obliged to check them at the door, and expect others to do the same. “[M]oral viewpoints threaten others within an organization by making claims on them that might impede their ability to read the drift of social situations.” As a result there is social pressure (one might say a moral demand) not to be too “moralistic.” This pressure is rooted in the insecurity of managerial careers.

Crawford describes his experience of getting paid for motorcycle repair – where a wad of $1000 in cash given to him by a happy client was somehow more rewarding than the same amount given for an office job. The reason is because the motorcycle either runs or it doesn't, while at the office he was not being judged based on the results of his work.

First time I got paid for building a piece of software was when I was 13 and I wrote a Lotus 1-2-3 macro for a small business and got paid $50 for it. When I worked for a couple of years as a consultant getting my timesheet signed every week and realising that my customer will be utilising my services for another quarter was highly rewarding. Likewise, I am uncomfortable in environments where metrics for performance and compensation are arbitrary and subjective, as most engineers should be.

Whether you agree with Crawford's views on corporate culture or not he does offer a sobering and honest viewpoint on the modern work ethic. It is a must read for anyone considering themselves an engineer and even a manager. It is one of those rare books that offer a society a look in a mirror undistorted by modern culture.






  1. Note how Java EE 7 tutorial does not include a section on development roles, which is a sign of evolution of management techniques in recent years