Proudly Mundane: Software Development as a High-Skill Trade
Imagine yourself facing a difficult medical situation. Having been referred to two possible specialists, you talk with both to try to evaluate which one to work with. In the spirit of a classic interview question, you ask both of them why they choose to practice medicine.
The first doctor’s eyes sparkle with intelligence and enthusiasm. “I consider myself a medical artist!”, he exclaims. “All of my procedures are truly one of a kind. I love going to work every day and expressing my unique vision in my work! We have a saying in my office that’s almost a manifesto: ‘Strive for practitioner happiness!’”
The second doctor is steady if aloof. “Well, my dad was a pipefitter,” she explains. “Really medicine isn’t that different. You apply the tools and skills to solve physical problems as best you can. I guess some people might think it’s boring to solve the same problems over and over. But so far I haven’t gotten tired of just putting my head down and seeing the results it has in my patients’ lives.”
Art versus trade
I propose three general categories of creative endeavor: Art, craft, and trade. All three require skill, knowledge, technique, technical mastery. All three can be executed in an attitude of service. But they differ in their goals, and in the relationship between the author and the work.
In the realm of art, the goal is communication, expression, novelty, and individuality. Utility is generally not a consideration. The creations of a master artist are imbued with the particular character of their creator. Even people uninterested in art can often identify works by Van Gogh, Monet, Andy Warhol, or even Bill Watterson merely by the style. This uniqueness of vision and execution is part of their true value.
In the realm of trade, the goal is to meet practical needs and solve practical problems. Utility is the metric. The aesthetic impacts of a machine, a road, or a power transformer matter as far as their practical impact on the wellbeing of the environment and its inhabitants but are not an end unto themselves. In no circumstance is the goal to express the unique character of the tradesperson. On the contrary, the creations of a master tradesperson leave no particular trace of their creator. If a real estate developer extolled the visionary nonconformism of the plumbing system of a proposed hospital expansion, investors and executives would appropriately end the conversation then and there.
Somewhere in the space between art and trade lies the broad continuum of craft — where utility and the application of widely understood techniques meets aesthetic distinction. The goals are a variable mixture of utility and beauty. The satisfaction for craftspeople is often in the balance of these two goals.
Software development is a trade…most of the time
I consider software development as the direct digital equivalent of machine building. Most of the software in the world, like most of the physical machinery, exists outside of public or consumer awareness. Even consumer devices — from fancy smartphones to cheap blenders — are mostly built from parts that are not visible to the user. In both the digital and physical cases, building these machines is straight engineering and trade work. Utility is the only meaningful measure, with the caveats noted above about environmental impact. When side effects (externalities to use the formal term) are included in the consideration of utility, there are no caveats.
However, there is a broad surface of craft and sometimes even art where software touches the world, particularly when the interface is with consumers. The aesthetic aspects of consumer software and digital media are intrinsic to their value. The visual and audio aspects of some games are unequivocally in the realm of art. As with physical equivalents such as device design or interior design, well-executed software craft requires both aesthetic vision and technical understanding of the available tools and materials. A design that can’t be built is not a good design.
And yet well-built software, like a well-built machine or well-built building, intentionally separates the foundation of pure trade work from the surface of craft and design as much as possible. It’s a general foundational principle to design systems of all kinds to have minimal dependencies between components. This is just as true for minimizing the dependencies between UI or design features and the bulk implementation of the logic, storage, and processing that the UI is built against. The demands of design and craft in software visuals are real and important, and they should be segregated to the greatest extent possible from the functional implementation. Mixing roles and working against specialized skill sets is a great way to squander human resources. Architects are neither engineers nor electricians and vice versa. The rare individual who has all these skills does not remove the need to keep the roles and implementations separate.
I’ve spent so many words arguing this trade perspective because so many developers don’t seem to see it this way, and so much bad software is built because of it. I myself have in the past used the term “craftsman” to describe my work, and that has been true in the cases where I have built games or even business user interfaces. But, especially when other people are paying for it, I’ve come to see the craft-first or even artist-first perspective in software development as an actively bad thing. Developers who are especially interested in “expressing themselves” or gratifying themselves with novel creations and elaborate puzzles are actively working against their actual job: to build something useful. Enter my analogies above to medicine or plumbing.
Even at 70 years old, software development is a relatively young field, and the constantly changing technology is largely not understood by the broader public. This puts software developers in a unique position of power vis a vis their customers and employers. The demand for our skills exceeds our availability, and most of the people who pay us don’t understand what we’re actually doing. Far too many developers abuse this position by pursuing self-gratification over utilitarian service. Many even actively and vocally promote this perspective.
What about innovation?
Skilled trades, software development (and medicine) included, are full of opportunities for creativity, problem-solving, intellectual challenges. Likewise, there is endless opportunity for innovation, but it should be measured very differently from innovation in art. A key distinction is in the ease of imitation. The most profound accomplishments in the art are precisely so because they are so difficult or even impossible to imitate. Their singularity is part of their value. They continue to surprise even on repeat viewing. It is the exact opposite in trades. The most profound accomplishments in technologies and trades are valuable precisely because they can be readily understood and copied by even mediocre tradespeople in the same field. They seem somehow obvious on the first encounter, and only more so with increasing familiarity.
On beholding artistic innovation, people ask “How did they do that?”. When they encounter innovation in trade, they ask, “Why didn’t I think of that?”
This is truly where the rubber hits the road in software development. Due to narcissism, ignorance, or the self-gratifying pleasure of creating intricate contraptions, even highly intelligent developers have a recurrent habit of building software that is awful not because it doesn’t work (at least at first), but because it is saturated with novelty, complexity, and “opinion” for its own sake. And they call this “innovation.” I call it technical debt.
I don’t agree with the perspective that any technical problem or solution should be explainable to a layperson. It is reasonable to expect that it takes time — sometimes many years — to attain sufficient knowledge and experience in a technical field to be able to understand or function as a full-fledged professional. This is not the same thing as expecting other professionals to spend hours or months disentangling the intricate creations of a self-styled code artist.
To developers who regard themselves geniuses: It is not other developers’ jobs to ascend the heights to your rare and inscrutable genius, to toil away through riddles and trials like some pilgrim seeking enlightenment. Actual genius developers create platforms, patterns, and tools that average developers can understand, maintain, and extend.
What about developer happiness?
It is totally reasonable for all humans, including software developers, to want to have good working conditions, to feel engaged and fulfilled in their work. Tradespeople derive this satisfaction from working with high-quality tools, on well-managed projects, building things worth building. They express creativity in coming up with apt solutions to the infinite variations in requirements and problems encountered. They also enjoy the rhythm of simply executing, where there are things to be built but nothing to be invented. People who find this boring, who are more motivated by a desire for individual expression than by anonymous contribution, who take more pleasure in compounding complexity than striving for simplicity, who yearn for subtlety and cleverness over obviousness…these people are not suited for software development. The world would be a poorer place in every sense without these personalities’ contributions to arts, politics, and other endeavors that even require a level of narcissism and singularity to succeed and contribute. Software development is not one of those endeavors.
~Josh, Software Developer