Ted TschoppA Letter to the Artisanal Software Craftsman
Less then a decade ago, a Software Developer was a programmer who created software through direct, personal engagement with the code. Their craft lies in the accumulated judgment, taste, discipline, and care they bring to the work: understanding the problem, shaping the architecture, writing each implementation, and refining the result through deliberate inspection. They still use the technology of programming languages, development environments, compilers, debuggers, libraries, frameworks, and automation—but retain human authorship and comprehension as the central means of production.
Their technique in using this technology (yes, those words are related) is the repeatable practice through which that craft is expressed: decomposition, abstraction, test-driven development, code review, refactoring, debugging, performance analysis, and careful use of documentation. The master craftsman embodies a production philosophy in which quality depends on the developer’s cultivated skill. Like other artisans, they value control, traceability, and intimate knowledge of the finished work.
Technology
The term technology is related to the term technique, by technique I mean a deliberate and repeatable way of doing something; the arrangement of actions, tools, timing, and attention that makes a result more likely. The English word arrived in the early nineteenth century through the French technique, initially referring especially to the practical methods of art and musical performance. Behind it lies the Greek technē: art, skill, craft, or a reasoned method of making and doing. That ancestry matters because technique did not originally mean a sterile procedure separated from creativity. It described practical knowledge embodied in action: not simply knowing that something should be done, but knowing how to bring it into being.
Today we most readily recognize technique in activities with visible physical performance: a pianist’s touch, a painter’s brushwork, a surgeon’s incision, an athlete’s movement, or a programmer’s approach to decomposing a problem. But technique also shapes less visible forms of work. There are techniques for listening without becoming defensive, asking questions that expose assumptions, structuring a meeting, calming a frightened child, diagnosing an incident, writing a useful prompt, reviewing a decision, transferring knowledge, and introducing organizational change. Even governance has technique: the sequence in which evidence is presented, the way exceptions are framed, and the design of feedback loops can determine whether governance improves decisions or merely slows them down. Technique is therefore not confined to the hand. It can be social, intellectual, emotional, organizational, or computational.
Craftsman
The term craftsman, is related related to the term craft, and by craft I mean the disciplined ability to make something work well in the real world; not merely possessing knowledge, following instructions, or producing an object by hand. The word comes from the Old English cræft, which originally meant power, strength, or might. Its meaning expanded to include skill, dexterity, art, science, talent, and eventually a trade requiring specialized ability. Craft was therefore never limited to quaint handiwork. It described human capability: knowledge made practical, judgment developed through experience, and the power to turn intention into a reliable result.
That older meaning remains hidden inside many of the ways we use the word today. Craft can mean the practiced skill of a carpenter, writer, engineer, or performer; the collective members of a profession; the careful construction of an argument or strategy; and even the cunning required to achieve something indirectly. It also appears in statecraft, tradecraft, stagecraft, witchcraft, watercraft, aircraft, and spacecraft. These uses may seem unrelated, but each concerns the knowledgeable exercise of power within a particular medium—wood, language, politics, intelligence, perception, water, air, or space. Even modern labels such as “craft beer” invoke a promise that judgment, care, identity, and deliberate choices remain visible in the result.
Applied today, craft is not the opposite of automation, scale, standardization, or industrial production. It is what allows those things to be designed intelligently. As tools take over more of the physical production, craft moves upward: from personally performing every operation to shaping the environment, standards, feedback loops, and decisions through which good work can repeatedly emerge. This is how technology (from be base word technique which means the application of craft) evolves: it extends human capability by embedding judgment, skill, and experience into the tools and systems we create.
Software Development
Software development is a craft. It rewards curiosity, judgment, discipline, taste, and deep knowledge of the systems being built. None of those qualities disappear when development becomes more industrial. Industrialization does not mean replacing thoughtful people with an assembly line. It means making the routine parts of the work repeatable, observable, testable, secure, and recoverable instead of depending on memory, manual effort, and heroics.
I understand why some people resist this change. They have seen automation programs used as excuses to eliminate jobs. They have been handed unreliable tools by leaders who did not understand the work. They have watched management celebrate generated code while ignoring the cost of reviewing, repairing, and operating it. Some are afraid that a profession they spent decades learning will be reduced to typing instructions into a machine. Those concerns are legitimate. They deserve honest answers, approved tools, meaningful training, protected time to learn, strong engineering controls, and a voice in how the factory is built.
But refusal is not a strategy.
In an enterprise, choosing not to use AI is no longer merely a personal preference about how someone likes to write code. It affects how quickly vulnerabilities are repaired, how long customers wait, how much work falls onto other team members, and how much the organization must spend to make a change. When safer and faster methods become available, continuing to rely on handcrafted procedures, tribal knowledge, manual testing, and heroic effort transfers the cost of that preference to everyone else.
No one should be expected to trust generated work blindly. AI should be questioned, bounded, tested, monitored, and audited. Skepticism is part of the job. There is an important difference, however, between refusing unsafe automation and refusing to learn how automation can be used safely. One is responsible engineering. The other eventually becomes an organizational liability.
The truth is that a developer who categorically refuses to work with AI will increasingly resemble an engineer who refuses a compiler, a PC as opposed to a mainframe, a modern programming language as opposed to C or Assembly, source control as opposed to folder, automated testing as opposed to an independent testing team, or continuous integration and deployment as opposed to manual deployment. That person may still be talented. They may still produce excellent code. Their experience may remain enormously valuable. But an enterprise cannot base its future operating model on a method that does not scale with the growing volume, speed, and complexity of change.
Craft & Technique
Today I think many people confuse technique with craft. They see the steps and the tools and assume that following them is sufficient. But true mastery requires understanding the principles behind the methods and knowing when and how to apply them wisely.
Craft and technique do align, but they are not identical. Technique or technology is the method; craft is the cultivated judgment that governs the method. Technique tells a person the steps to follow to perform an operation, while craft tells them when that operation is appropriate, how carefully it must be performed, when it should be adapted, and when it should be abandoned altogether. A novice may reproduce a technique exactly, while a craftsperson understands the conditions that make it succeed or fail.
In modern time technology advances technique by automating many things. Computers may learn, generate, and execute many techniques, but craft remains visible in the framing of the problem, the selection of methods, the evaluation of results, and responsibility for consequences. Technique makes capable action repeatable; craft makes that action intelligent.
A Path Forward for the Artisanal Software Craftsman
A profession does not preserve its dignity by preserving its bottlenecks.
The developer’s role is not becoming less important. It is becoming more demanding. Developers will be expected to define intent precisely, expose hidden assumptions with more clarity, design durable boundaries with more foresight, judge evidence wtih more rigor, anticipate failure earlier, understand production behavior during design, and decide when AI generated work must be rejected. The amount of human typing may decline. The amount of craft required will not.
Leaders have obligations in this transition as well. They cannot purchase an AI tool, announce a productivity target, and declare that transformation has occurred. They must provide safe platforms, clear policies, realistic workloads, training, apprenticeship, and room for people to make mistakes while learning. They must reward people for improving the system, not merely for producing more code. Compassion requires helping people cross the gap. It does not require pretending the gap can be ignored forever.
Artisanal development will continue to have a place. Exploration, experimentation, unusual algorithms, prototypes, small personal tools, and genuinely novel problems may all benefit from an individual craftsperson working close to the material. But artisanal development cannot remain the default operating model for critical enterprise systems. Systems that support customers, employees, infrastructure, money, safety, or regulated operations must be built and maintained through processes that can perform reliably without depending on a particular person having a good day.
People are not obsolete. The old division of labor is. We should carry the judgment, ethics, creativity, and hard-earned craft of software development into the new factory. We should help one another make that transition with patience and respect. We should also be unflinchingly clear that standing still is a decision—and in an environment changing this quickly, it is a decision to fall behind.
