We, Programmers, are Gardeners
Too often you might see the profession of the software developer being associated with the practice of the artisan. This is a common trope, picked up mostly by people that feel detached from the other forms of engineering and by those interested in depicting our job as a concoction of creativity, discipline and mystical wisdom.
The metaphor of the artisan works well enough because the narratives of both figures are imbued with a mix of productive fervor, constant improval and gathering of arcane knowledge. We can all picture a craftman working late at night in his workshop, sculpting a piece of wood to be used for his next creation in the same way we can imagine ourselves at the same hour, with the same bright moon outside, bent over a laptop, vigorously banging the keys on our keyboards. Both are crafting a small, precious piece that only they can create in that way. Engineering might make use of that small piece of code but in that very moment there are no systems, there are no standards, no formats, no integration, no smoke-tests. It’s just you and the fruit of your labour growing under your hands.
Nonetheless I’ve always felt that this metaphor somehow missed the point. That’s because writing code doesn’t feel like forging a piece of metal or carving a block of wood. These are materials that are passive to the work of the artisans. They are shaped into the desired form and they rarely deviate from the expected behaviour. For sure, the quality of the material matters and an expert hand will treat oak differently from cherry or pine but still, it’s a dead substance.
The code though, when manipulated, presents behaviours that are more tipical of something… organical. Alive. With its own will. The semantics of the code lead its evolution together with the programmer. Also the language, the tools and the context in general contribute a lot more to the final shape of your code than just the sheer intention of the programmer.
This might apply to artisanal work to a minor degree but you will never hear a potter say: “I had this really cool idea for a vase but I ended up with a tea set for six people”. On the other hand, programmers, especially if inexperienced, will reach a result very different from the original design more often than not. Plants are alive too and while they accept the guidance and cure of the gardener, their characteristics lead their own life more than the expectations and desires of the gardener.
The experience of the gardener lives in the ability to use his knowledge of the plants, of the land and its tools to work around the obstacles posed by the traits of the living matter he wants to grow. In the same way problems, features, technologies, languages, customers, markets all have positive and negative traits and one cannot ignore them when developing a piece of code for the real world, nor can one change these realities to more easily achieve his goals.
This is critical, because it underlies another deep difference: artisanal work improves by repetition while repetition is to be avoided in programming. The only scenario where you’re likely to develop again something you already did in the past is when you find a new job in the exact same field of your previous company. Even then, with the same business requirements, similar environments and same technologies, it’s guaranteed that the system you will develop won’t end up looking like the ones you developed before.
A gardener at the beginning of the season can aim to reproduce the same layout as the year before, with the same seeds and the same land, but during the season he will incur in totally different problems and the end result might diverge deeply from the one of the year before: weather, bugs and diseases all contribute to the final result and these are mostly out of control as it is the chaotic complexity of living beings.
This complexity is mirrored on a bigger scale both for code bases and gardens: plants, like code, in most cases cannot be modeled in isolation. Plants live in an ecosystem, they have synergies with other plants and dislike some others. They need to be integrated properly, they need to be properly decoupled from the others and cleansed of weeds. Code is the same: you have small (hopefully) blocks you can compose to produce a service or a library, that then need to be further integrated with other components until the desired goal is achieved.
Gardens and softwares are systems and this dictactes a discipline to handle complexity that is characteristic of the Engineering world. Craftsmanship, on the other hand, almost never work with systems. They compose elements of different kind but they tend to be at rest, static. Their interaction is predictable. The complexity does not lie in the moving parts.
Reasoning on this topic is important to me because it helps to create the narratives our profession is lacking. While being more and more common job, programming is still deeply misunderstood by the general public for a variety of reasons. It’s not easy to create a narrative that can include the huge diversity of job roles that are generally referred to as “Programmer” and even if we find one, it doesn’t necessarily work on the stage of pop culture. Look at the representation of hackers: from the ’80s it dominates pop culture despite representing a microscopical minority of the IT world. Software development has nothing comparable to make use of. The hacker narrative is so strong that it’s still relatively common to hear jokes like “Oh, you are a programmer, so you can hack into the NSA”.
For sure the gardener won’t solve the problem but it’s about time to dismiss the artisan, the architect, the hacker and all the metaphors that are confusing and possibly detrimental to our professional category. This is important for everybody, because the way non-wizards understand our work is relevant for how we are treated, for the working environment we are offered, for the respect we are paid. The market might dictate our salary, but a profession is much more than that and right now, in my humble opinion, there’s still a huge gap to fill between the reality of our daily work and the social, political and cultural perception the rest of the world maintains in our regards.
Thanks to Lucille who inspired this article.
Edit: while I was quite sure this metaphor was so original, I discovered that there have been some quite worthy attempts to elaborate on the same subject. Here is what I’ve found so far:
Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about a gardening metaphor for software…www.artima.com
https://medium.com/@raulvillares/programmers-as-gardeners-146879535399