Laborer, Craftsman, and Artist

As part of the ongoing discussion of how AI and automation are being used and impacting the software development industry, it is important to define some basic terms and concepts. This group of terms seemed appropriate on Labor Day — talking about the “Laborer, Craftsman, and Artist” and the distinctions between them.

“A man who works with his hands is a laborer;

a man who works with his hands and his brain is a craftsman;

but a man who works with his hands and his brain and his heart is an artist.”

This quote is affectionately attributed to St. Francis of Assisi, but more accurately to 1920s lawyer Louis Nizer.

Having worked in software development for almost 30 years, it has been great to participate in and witness a lot of the “labor” of building software products and systems. Also, the idea of pragmatic and clean “software craftsmanship” and architecture and engineering have also emerged as strong disciplines and themes in the industry. But the idea of “artistry” has been more elusive — until recently.

Watercolor Painting

One quick aside short story: during the pandemic, I took up watercolor painting — and I hit it hard; I studied the techniques, pigments, physics of light and colors, materials, and an amazing number of tangents. One of these ended me up in a professional watercolor class by a master artist. In the four-day retreat, I was by far the most novice among those at the workshop. One of the lunchtime discussions moved into the difference between “craft” and “art.” I was intrigued as I had never thought to differentiate the terms before. The conversation went on to discern that there are those who use watercolors to create “crafts” and those who use watercolors to create “art.” I very quickly realized that I will most likely be, at best, a “watercolor craftsman” and not an “watercolor artist” and even then, only with a lot of practice and focus. Let me explain.

So, the “laborer” in the case of watercolor painting is really knowing how to use the pigments, paper, and techniques to get quality results (you can really make an awful mess or “mud” with watercolors). The next step would be a “craftsman” who would know when to use different techniques, follow a plan or definable-repeatable-process, and know when to use which products and methods and when not to — and not only know these things but have the experience to know when each of the different tools and techniques would achieve the best result. The master teacher in the class I took made the case that some of the most famous names in painting could be said to be more “crafting” because they often create very similar paintings from a repeatable formula (some of them featuring idyllic Christmas scenes) — these are very beautiful and successful and can be profitable.

Being a talented craftsman can create a very beautiful, successful and profitable result.

But “artists” have a unique gift and create results that are one-of-a-kind and have a singular beauty. They capture a sense of color, value, composition, content, form, and style that can be unique and impactful. This artistic sense and ability are rare and not necessarily aligned with monetary success or fame — there are a lot of “starving artists” out there. But the results are excellent, unmistakable, and admirable. And how do you recognize it — more on this a little later.

Software Laborer

In software development, there is no doubt that basic skills and abilities need to be achieved to become what might be called a “software laborer.” These are learning the basic syntax of different languages and the frameworks and standards that enable modern applications. There are many paths to this knowledge, from formal classes and schooling, to bootcamps and workshops, mentoring, or even self-study. The need for the ability to learn these basic software labor skills is foundational and critical for success in the successive levels and can not be skipped or avoided without consequences

The need for the ability to learn these basic software labor skills is foundational and critical for success in the successive levels and can not be skipped or avoided without consequences

In the last few decades, tools have increasingly emerged to make this labor lighter. Long gone are the days of just using a text editor to enter code and a compiler to build it (let’s not go back to punch cards). Today’s editors are even “IDEs” (integrated development environments) with plugins and pipelines that will give instant feedback on code as (or before) you type it, and check if it will build, and run unit tests in real time. Once the code is complete, tested, and reviewed, the pipeline and path to production are also condensed and streamlined to the point where code can be mere minutes from being deployable or even deployed. These tasks used to take individuals and teams of individuals much more time in the recent past.

As you can imagine, what will emerge from the discussion of the advances of tools for automation and AI is that the productivity advances of these tools will cut the workload of the labor down significantly and reduce the overall need for those working primarily as pure laborers as coders. The need for “pure software laborers” is becoming rapidly reduced, and entry-level job descriptions and responsibilities are changing.

The need for “pure software laborers” is becoming rapidly reduced.

Examples of books and resources in the area of building up skills in “Software Labor” are too numerous to really mention and are very tool or language-specific. But the important part at this stage is to find a path to study and, more importantly, gain experience in writing code and code that will be used in a production environment.

Software Craftsman

Our workforce’s need continues to shift to demand more “software craftsmen” over laborers. When one has the equivalent of a “nail gun,” it becomes much more important “where the nail goes” or even “where the board or beam” goes than how to get the “nail into the wood.” (or even should I just ‘buy’ a prefabricated beam in the first place?)

While much of the wisdom and ability that lead to skilled software craftsmanship comes from experience and discipline, a lot can also be studied and learned in this area. They say it is wise to learn from your mistakes, but it is even more wise sometimes to learn from other people’s mistakes.

While much of the wisdom and ability that lead to skilled software craftsmanship comes from experience and discipline, a lot can also be studied and learned in this area.

Developers have been at this work for decades and have found many things that have worked very well and other things that have not worked very well. These things that have worked well have been collected into standards, and guidelines, and frameworks, and patterns that are widely used and accepted across the software industry. Reading, learning, and adopting these into practice will go a long way to improving one’s craft.

There are also many current and live conversations ongoing about the craft of software development. There are online and in-person conferences, discussions, and user groups who regularly ask and answer each other’s questions and share their experiences (good and bad) with one another. In this way, the new and emerging technologies continue to be discussed, as well as the tried and true elements of craft that need to be shared with each wave of new developers. There are good national and industry/vendor conferences. Still, from my experience, the regional and even city/local conferences have been the most valuable for me for both great content and contacts and the ability to interact and learn from both.

Some examples of writers and speakers who come to mind immediately in the “software craftsman” category are:

• Martin Fowler — his work in the areas of Design Patterns and Refactoring, specifically, are particularly helpful in helping to guide developers to focus on consistency, pragmatism, and purposefulness in their work to help build quality and continuous improvement. Fowler also promotes and writes often on tools and techniques that help to enable collaboration and communication within systems and the people who build them, which are critical to success. Fowler’s writings can also span into “art” but have much to say in this area.
• “The Pragmatic Programmer” by Andrew Hunt and David Thomas and related and adjacent works have also become key sources of wisdom for aspiring software craftsmen — almost for pure craftsmen, not “over art” but in approaching development and mastering it as a craft first and foremost. This book covers key architectural concepts, guidelines, rules to live by, tools to use, and when to use (and not use) them, how to test, and prototype, and design, and debug, and continue to improve and adapt (yourself and your code).

Software craftsmen are arguably the most valuable segment in our growing automated and AI-augmented industry. This fact isn’t new, but is becoming even more critical now that the tools are leading to hyper-productivity and output of code and other deliverables.

Software Artist?

But what about “software artists?” And what would it even mean to “write software with your ‘hands, brain, and heart’”? And is this any more or less valuable than, say, a talented craftsman?

What makes good art?

A few articles and textbooks on the subject offer that “good art” …

• Is beautiful, clean, balances form and function.
• Evokes an emotional response.
• Evidences quality skills and technique.
• Has a long lasting impression, makes a statement.
• Achieves a purpose, has meaning, tells a story.
• Is something unique.

I could offer some questions that software may be art if …

• Have you ever read through some code and just thought to yourself “wow, that is some beautiful code?” — another clue you may have “art appreciation” is that you just like to randomly read through other people’s code, like open source repositories, even as if other people are reading a book, and enjoy doing it. It is like other people reading poetry or scientific research — reading another person’s really good code can be inspiring or uplifting. If this sounds odd or foreign to you …
• Have you read code and thought about how “efficient” or “elegant” it was, or “what an amazing example” of a particular solution or algorithm?
• You’ve used some software or a library and come away with a feeling of delight or thankfulness for a pleasant experience and even surprise at unexpected features or power or usability
• Anti-art examples are feelings of even anger or disgust (beyond disappointment) at some particularly bad code that broke some of the basic rules of software development and trust and “honor codes” between professional developers.

Some examples of writers and speakers who come to mind immediately in the “artist” category are:

• Donald Knuth — here is a guy who spent a lifetime writing the literal “The Art of Computer Programming” (which got its own acronym TAOCP) over decades of cataloging and explaining algorithms and the art of computing, and is still incomplete — in the process, he created a typesetting system for this effort TeX and METAFONT to support the effort (which has since become a standard for many other technical journals and publications and typefaces) while promoting “Literate Programming” which “emphasizes the importance of writing code that is readable by humans.” All the while having fun with it by offering a “bug bounty” of sorts of one “hex dollar” ($2.56) (p.s. fun all by itself) to anyone who finds and reports a legitimate error in one of his books.
• “Uncle Bob” — Robert C Martin — who has written the “Clean Code,” “Clean Coder,” and “Clean Architecture” books writes and talks about beautiful and elegant software design principles and also bridges the gaps into Software Craftsmanship and Agile Principles, Patterns, and Practices.

Art, cont. — Passion and “the Spark”

This is where I get in trouble with some people, and I would welcome feedback on this post. But in my time in software development, I have come to experience and believe that there are some people who have a certain something extra — a “spark” or a “passion” or a “gift” — for working with software and systems and processes and people that goes beyond something that can be learned, or trained, or experienced. This is something that goes beyond a computer language, or syntax, or framework, or systems. And it’s related to some of the emotional language from some of the sections above — do you “love to code” and get passionate and excited when a good day or session of coding happens, and the opposite side of this can be some negative emotions of sometimes extreme disappointment, the vast majority of the time with oneself, when success is not achieved.

You might have the spark of software artistry if …

• You code “for fun”, you enjoy reading code
• Scribe parum cotidie _— “_write a little every day”, originally a saying for authors but also true for artists of all kinds, if you go for a day or more without creating you feel the loss of time and a longing to return to the creative process.
• You have stories. Some of the first code you wrote, the best code, the worst code, who you were with, the problems you were solving, the problems you overcame, the achievements that made it to production, and the systems that took their place only a few years later.
• You have hopes and dreams and technologies and trends you are actively following — while also appropriately skeptical, you have an ear out for the ever-evolving and quantum changes in technology that enhance and disrupt the technology and development landscape on an ongoing basis.
• You like solving logic puzzles — this also means that the triage process or even debugging might be a favorite part of some days of development. Determining the cause of a system glitch or failure (and possibly resolving it) is an enjoyable part of the day
• Talking about coding is like talking about hobbies or other interests or pastimes — even honest debates about competing strategies or approaches to solutions to problems or implementing features.
• If you won the lottery or “retired” or the income alone was not the primary factor … would you still code? regularly? every day? (the projects would change, but would you still code?)

If you retired, would you still code?

Sounds a bit geeky, perhaps odd, and that’s ok. But these are also aspects that are not universal and in no way required to be a very successful and talented software craftsman, or architect, or otherwise be involved in the software development process.

BUT, if this is you, share some of this with those around you — it is an important energy and fuel to a team and group of people who are coding and working together. If this isn’t you, find someone who’s got the spark and passion and spend some time working together, as I can tell you from experience that these relationships and bonds are what will enable an extended career of success, and help work through challenges and burnout and all the hurdles that have yet to come