Can programming be a craft? I was thinking about this as I was reading Matthew Crawford’s excellent book The World Beyond Your Head. Much like Crawford’s earlier work Shop Class as Soulcraft, he argues that craftsmanship is an activity that doesn’t just provide us with satisfaction, but also makes us fundamentally human by enchanting us with the world right around us.
He provides the extended example of musical organ makers, who work on instruments that are designed to last centuries. They innovate, but within the tight context of a lineage of apprenticeships that goes back many generations. While repairing an organ, an organ maker can identify the marks and craftsmanship of his or her historical peers, recognizing great or slipshod quality that occurred several hundred years earlier.
There is a reverence in witnessing the craftsmanship of skilled artisans, but Crawford is careful to argue that reverence does not mean sycophantic obsession with the past. Instead, he makes a persistent plea to avoid seeing tradition as constraining, but rather considering it as a base upon which to innovate on. There are rules, yes, but those rules come from the deep experience of those before us. Better to consider their purpose deeply rather than replace them in a callow attempt at newness.
What gives craftsmanship its fundamental character is the progress latent in the work. Works by young novices can be easily distinguished from the works of experienced masters, and following a single craftsman’s career can be enlightening as they learn their trade.
Returning to my opening question then, should we see programming as a craft? The glib answer is yes, of course it is. There is a skill that is developed over time, and masters hopefully understand the field better than novices. Quality work can be identified by other masters, and at least some programmers have reverence for the computer that Crawford’s organ masters would find recognizable.
Yet, I can’t help but feel that programming is far from being a craft. Reinvention is fundamentally anathema to craftsmanship, for quality has to build up in layers of skill over time. In programming though, it’s not just the code we write that is constantly being throw away, it’s the entire toolkit. Programming languages ebb and flow in popularity, models and frameworks appear and disappear. Three whole new programming paradigms will be in vogue in the time it takes an organ maker to construct one instrument. Nothing in this field is timeless.
Taking a chisel to stone can create an artifact that can last millennia, and inspires such awe we build magnificent palaces to put them on display. Yet, when code stays in production for too long, we aren’t enchanted, but actively disgusted. That COBOL mainframe at the heart of the bank from the 1960s-70s isn’t something to revere, but rather something that needs to be replaced, something that needs to be “modernized.”
There is a concept in sociology and evolutionary sciences for that obsession with constantly improving known as the Red Queen principle, which is the amount of energy it takes to maintain our social status (from Alice in Wonderland’s Red Queen, who says that “it takes all the running you can do, to keep in the same place”). In programming, this is represented by the constant background learning required just to maintain an up-to-date knowledge of the field.
That’s not just theoretical, it’s been my experience as well. I started programming in elementary school with HyperStudio, and moved on to a TI-86 graphing calculator programming TI-BASIC. TI-BASIC is exactly what it sounds like, and it was a joy seeing a small program take inputs, transform them to outputs, and getting immediate feedback on whether the “app” did what I wanted it to do. I made choose-your-own-adventure games and a Tic-Tac-Toe game (complete with what a startup might call “AI” but is probably better referred to as a deterministic finite state machine).
Much like the organ makers in Crawford’s book, I had mentors who volunteered at school to teach me more about this craft. I learned more control structures to manage my code, and best practices on how to encapsulate functionality to make code reusable. I “discovered” priority queues and other data structures in high school, only to find out later that such things had been invented before I was born. That was exciting though — I was part of this programming lineage, and it was a blast.
As I left my job last year, I started re-learning programming, trying to “modernize” my skillset in the Red Queen fashion. As I wrote on Medium at the time, when I last worked with JavaScript, jQuery had just been released. So there was a lot to learn as any modern web developer appreciates. I spent a few months learning what had changed, and then tried to implement some applications I had been wanting to build for the past few years.
And I stopped, burdened by the sheer amount of effort it takes just to get the most basic of apps running. Maybe I have changed as well, but programming just didn’t inspire the same level of awe as it did before. It didn’t feel so much as a craft as a never-ending trial of stamina. It just wasn’t fun, in the sense that I walked away after an afternoon with a sense of joy at the creation that I had unearthed. I walked away instead with JSON type errors and some weird Chrome bug.
Professions and crafts are heavily correlated. A veteran surgeon has seen thousands of patients, and can apply the pattern recognition and judgment — the quality — that has been developed over a lifetime to ever more complex cases. A writer can watch as their craft improves article by article, edit by edit, tackling harder and more nuanced subjects with finesse.
In programming though, we throw away our most experienced. Age discrimination is rampant in Silicon Valley, because the old ways of doing things are just that: old. The only knowledge that matters is the knowledge that came in the last few years. No field has greater amnesia nor a greater desire to reinvent itself as rapidly, and that to me is a problem worthy of solving.
There is a need for something of a “slow code” movement, one that doesn’t reinvent the wheel every few years. A movement toward more stable and complete libraries, of languages that don’t break backwards compatibility. Of seeing the field as a craft and part of a long lineage of intellectual forebears instead of as a terrain where the masters need to be overthrown for the latest junk to be installed.
I do want to address some obvious criticisms. One is what might be called the computer science / programming distinction. University computer science programs train students on concepts like algorithm design, automata theory, and probability theory since these concepts are considered timeless. That may well be true, but what this model gets wrong is that algorithms aren’t crafts. You cannot make something with knowledge of the O(n) performance of merge sort or what Rice’s Theorem is. It’s the difference between building organs and studying music theory.
Another critique might be to avoid certain programming environments due to their complexity. Web development and app programming are just flagrantly bad platforms for craftsmanship, and one should start with a more hobby-friendly platform like maybe a Raspberry Pi. There is some truth here, and that’s a fair option to take. But if programming is a craft, why do we need hobby-friendly tools at all? Why aren’t our existing tools sufficient for the craft?
A third criticism is one that I admit is a bit harder to address: isn’t the rapid evolution of software engineering fundamentally a good thing? Programming is a very new field, and we are still learning the intricacies and best practices in a way that the physics of bridge building was discovered millennia ago. Shouldn’t we throw out the old, since it is actually old as in archaic?
I admit I don’t have a great answer here, as there is indeed something to be said for reinvention. However, I would ask a simple question: has all the newness of our code ultimately improved the end-user experience? Does our modern model of cloud delivery of software services synchronized across data centers actually improve upon installed software from decades ago? I can imagine some reflexive “YES!” answers, but I would take a step back and ponder that question deeply. More features than before? Absolutely. Better productivity? Better experience and design? To me, there’s not an obvious answer, and that is telling.
Ultimately, this isn’t a plea to make programming better for hobbyists, it is a plea to make the field hospitable to all of us. It is a push to think about permanence, on how to write code that can stand up for years to come. Ultimately, it is a request to think in terms of creating a field that makes us more human in Crawford’s conception, as craftsman who can continue a lineage of excellence. Programming can be a craft, but it truly isn’t one today.
Comment