blogstrapping

The Crafty Coder

(updated 2017.018.20.32.54)

The term "craftsman" is unfortunately afflicted with a historical gender association, but alternatives are clumsy and distracting, overloaded with (often contrary) buzzword uses, lacking in appropriate nuance, or some combination of more than one of the above. Let the gendered form of the term not stand in your way. Both men and women may be craftsmen; other-gendered people may be craftsman, for whatever gender identification may apply; and in fact we may not be many years away from craftsman who are, in fact, artificial intelligences.

TL;DR

To paraphrase the old sage, I did not have time to write a short essay, so I wrote a long essay. A better, earlier essay of mine on the subject of software craftsmanship is also much shorter, though it represents a somewhat different perspective on the subject. I believe these essays are complementary, or perhaps supplementary. If you do not have time to read this essay, read The Woodcutter's Craft instead. If you do have time to read this essay, read The Woodcutter's Craft as well -- probably first.

That said . . . here's my take on the work of the crafty coder.

The Amateur Craftsman

The word "amateur" comes from the Latin word for "lover". The American Heritage Dictionary defines it, first, as "One who engages in an art, science, study, or athletic activity as a pastime rather than as a profession." An amateur craftsman, therefore, pursues a craft for the love of the craft.

Among the implications of this are:

Quality work is central to the love of a craft, with attention to detail intrinsic to the fact of enjoyment. Any true "amateur" craftsman -- one who is a lover of the craft, who deeply cares about the quality of work produced -- develops opinions and useful observations. Many of them may even disagree, sometimes almost violently, about matters that may seem entirely esoteric or even inherently opaque. This kind of confrontational opinionation is, perhaps surprisingly, often a good (but neither necessary nor sufficient) sign of the craftsman's dedication to doing quality work.

The Professional Craftsman

It is the job of the professional to work oneself out of a job. By completing quality work, by conveying an understanding of the work to the client, and by doing work that helps clients achieve these same goals within their own personal and professional lives, the professional works toward the day one is no longer needed.

Many people want to just hand something off to an auto mechanic one day, pick it up the next, and never understand what happened to the car between those times or even what really precipitated the need to get the car fixed. Despite this common case, an auto mechanic who takes the time to try to explain things to a client to help ensure the problem does not recur, and to ensure the client can do something next time around before turning to a professional to minimize the costs and other inconveniences involved in retaining someone's services to maintain continuing smooth operation, is the auto mechanic with a healthy, ethical ethos of the craft.

The Code Craftsman

Every craft comes with its own culture, its own set of characteristics common to quality craftsmen, and its own (sometimes contradictory) requirements and motivational factors for quality work. Software development is rife with its peculiarities along these lines. The term "software development" is also deceptively simple beside the reality of what it labels; software development constitutes a myriad of related crafts, each with its own differentiating versions of these peculiarities.

Some generally applicable truths seem to emerge, however. Examples include DRY (Don't Repeat Yourself), the Law of Demeter (or Principle of Least Knowledge), and the principles of the Unix philosophy (encompassing composability, minimal responsibility, and generality of design: "design small tools that each do one thing well"). A synthesist and systems thinker might derive more generalized principles that govern the beneficial nature of techniques that enhance the quality of code craftsmanship, though. Consider the abstract principles of leverage and virtue:

Leverage

In general, the best innovations are those that enable further innovation. One of the most remarkable things about this period in human history is the simple fact that the technologies we have available to us are more broadly accessible, and serve better to enable further technological advancement, than at any previous time. As remarkable as that is, it is also pretty singularly unremarkable, in that it has been true of essentially every moment at least as far back as the dark ages, and limiting it there is likely a Eurocentric conceit. It will also continue to be true for every moment in the foreseeable future.

The most empowering characteristic of technology is the leverage for further advancement provided by the introduction of previous generalized advancements. Almost all technical principles of good software design embody some aspect of this principle of innovative leverage. Three examples come to mind:

Virtue

Software development, as a field, represents one of the most important technological advances in human history. It is the magical act of defining systems for automating automation at a level of abstraction unsurpassed -- unless you count metaprogramming as a distinct field. Archimedes is credited with the idea that, given a long enough lever and a stable fulcrum, you can move the world. The lesson to take from this is that greater leverage provides greater power to effect change. Block and tackle provide additional leverage when connected to a simple lever, but parallelization of effort is achieved when you attach a water wheel to the block and tackle, allowing for additional effective leverage by freeing the human operator to work on something else at the same time, thus automating the system, only requiring enough attention from the operator to disconnect the apparatus when the job is done. Automated control systems can abstract away that part of the operation as well, so that we no longer need to even devote that scant amount of attention to the initial task.

Computers, as we generally understand the term today, greatly increase the flexibility of automated control systems, and software development allows us to increase the sophistication of these systems' flexibility of application. Every time a software developer performs the same task several times, that developer should consider automating the task. The most productive software developers spend their lives spawning automated operations, sometimes new and discrete operations, and sometimes meta-operations that are each composed of groups of other operations that are, in turn, each potentially composed of still other operations, to arbitrary levels of sophistication.

The leverage provided by so much automation and parallelization of effort yields power on an ever-growing scale, ever more difficult to measure as it grows. The truth of the matter is that a well-design automated system can provide power through not just primary, but secondary, tertiary, and even more indirect benefits, not only in our own hands but in the hands of others who pick up the same tools and use them in unforeseen ways. Considering the implications of every reusably-generalized software module can be a dizzying experience sometimes.

With great power comes great responsibility, though, as your friendly neighborhood trademark might say. To the extent that we do not exercise that responsibility wisely, the damage we do can undo all the benefits our work could otherwise provide, and the indirect benefits can be eclipsed by indirect detriments as poorly designed reusably-generalized software modules not only end up wasting users' time (as in the case of, e.g., point-of-sale systems), but can even stand in the way of the development of improved solutions to the same problem. A software development craftsman, then, must consider the implications of decisions made in the practice of this craft. Some examples of the generalized principle of virtue may be in order:

Conclusion

Care about your code. If you have any talent for it at all, approach your craft conscientiously with attention to even indirect consequences (both good and bad) of your work, learn as much as you can about it, and practice care for the product of your work at every turn, the rest will come naturally. On the other hand, if you find you do not love your craft not only in its immediate particulars but also in its potential (even when the work frustrates you), it is possible your calling lies elsewhere.

The final prerequisite for craftsmanship -- or, perhaps more appropriately, the first prerequisite -- is the love of the craft.