Software craftsmanship

May 22, 2018

Programming is a strange trade. As a programmer you spend your days atop a giant tower of abstractions and interfaces. To me it often feels detached, maybe even fictitious somehow, and yet I am connected very directly to the results of my labor. In Marxian terms, programming is not very alienated. When your job is to automate things, everything left for you to do is done by hand.

I think I first heard the term “software craftsmanship” shortly after I began programming professionally. I found it immediately appealing – it promised that this thing I was learning how to do might have some inherent aesthetic worth, that code I wrote might be beautiful and a worthy successor to the long and respectable traditions of other crafts.

Now, a few years later, I catch myself feeling irritated at the language of software craftsmanship which I savored before – “bespoke” or “artisanal” code seems to be missing a point. I enjoy my work and take pride in doing it well, but I think software craftsmanship as I usually see it expressed focuses on the internals of the software at the expense of the program itself. Maybe this is because the highest-profile proponents are consultants who have more control over the internals of what they’re building than over what they are hired to build in the first place. People who use the programs I write don’t care if the code is beautiful. They care if the program works. Striving for beautiful code feels like a self-interested concern, as if I were a woodworker taking pride in the beauty of my workshop instead of the pieces I make. It’s nice to have a clean workshop, but it’s not the point in the end.