I woke up this morning thinking about craftsmanship and programming.

Specifically, I think it's time to put this metaphor to bed.

I remember advertisements for Optimized Software Solutions (later ICD) that used the metaphor of craftsmen in need of precision tools, and extrapolating that metaphor to programmers demanding better software. It worked, because I'm still remembering these advertisements. OSS had fantastic tools on the Atari 8bit computers. But OSS was squarely in the "tools" category of craftsmanship. Their conceit was that buying their software was akin to buying a precision (possibly heirloom) tool.

(credit: Atarimania)

This metaphor has permeated the programming culture for quite a while. I'm not sure when it was first introduced but there is definitely an undercurrent of "craftsmanship" in programming discussions. The book "The Pragmatic Programmer" had a planer on the original book cover. 20 years later they've definitely been to Sears to get more tools.

Thing is, this isn't a useful metaphor for programming. I'm not sure it was ever a useful metaphor for programming. Woodworking craftsmanship metaphors are fantastic if you're comparing your expensive tools to the same kind of investment that someone would make for quality woodworking tools, but outside of this narrow scope I think the metaphor falls flat. For starters not every programmer is versed in woodworking (the closest most of us get to working with wood is assembling Ikea bookshelves to make more room for programming books, but I digress). The hope, I'm sure, is that we'll view programming as a deliberate act to improve upon but even this metaphor evaporates when compared to the "move fast, break things" mentality of the modern programming environment. Craftsmanship feels like a "nice to have" rather than a goal.

This also gets to the idea of quality as something to be bolted on to a process. It's that magic dust that we bring to our projects to make them 10-90% better. Just use your quality tool and you too can bring more quality to the process.

We treat quality like a noun and less like a verb or an action. I think that's a huge mistake.

There's a video that with Robert Fripp and David Singleton regarding an "Act of Quality".

Act Of Quality - Robert Fripp & David Singleton - Club Soda, Montreal - September 17th, 2022

In it Robert Fripp talks about the differences between carelessness and an act of quality. An act of quality is purposeful. It brings an intention and presence to the act. It's not something that can be measured ("we added 5% more quality to this" is a ludicrous statement. Sorry quantified self and metrics managers.) It's the act of showing up, of taking the time needed to make something great, and of thinking about who this is for and how will the user interact with whatever we're creating.

It's about throwing yourself so completely into the task and understanding the problem so fully that you can't help but improve the world in a small way.

Craftsmanship implies completion. Only the most obsessive craftsman continues to tweak, polish, and refine the work once it's shipped. I'm pretty sure our excellent kitchen table has never received a visit from the folks who built it to fix the varnish or oil the gears, or do any number of "bugfixes or improvements". But that's what we do with software we care about. We continually tweak, polish, fix, and yes, even deprecate our software. We have an opportunity to perform an act of quality every time we open the editor and devote ourselves fully to the task.

The metaphor of the craftsman was useful to a point. Lets shed it like we shed programming paradigms that no longer serve us well.

(And yes, I have read "The Art of Motorcycle Maintenance" by Robert Pirsig. It too was useful for its time. Much like "Walden" by Henry David Thoreau can we please let the 1970s have their headcanon and come up with our own?)