What does it mean to be a software craftsman? You can read the Manifesto for Software Craftsmanship and draw conclusions; but if you posed that question to different people across the software industry, you’d hear any number of different responses. And to some degree, they’re all true. Descriptions are ultimately bound to perspective, and there appear to be divergent perspectives on the software craftsmanship movement. What follows are three descriptions that are commonly wielded against the software craftsmanship community, accompanied by an explanation of the craftsman’s perspective on the same issue.
Craftsmen are arrogant.
A craftsman is on a lifelong journey toward mastery. Throughout this extended period of professional development, each craftsman is driven by the ideals of perfection. The closer you get to perfection, the closer you are to mastery. The two are inseparable ideals, but only appear as abstract concepts.
Even so, apprentices and craftsmen alike use deliberate practice methods like Katas and Code Retreats to try to reach this ideal. They refine keystrokes and hammer down syntactical nuances. Simply getting something done isn’t satisfactory to a craftsman in practice—it needs to be done perfectly and proudly. Their focus is fully on minor details, because those create the base from which their skill level can grow.
Software skill exists on an asymptotic curve. When you first learn something, you make large strides immediately and feel like you’re making serious progress toward perfection. But as time goes on, and as you increase your familiarity with the subject, your progress becomes more incremental. You’re not yet perfect, but the big strides have more distance between them. Yet, the craftsman persists. Even as deliberate practice yields diminishing returns, the craftsman plugs away. From the outside, this can seem like a vain attempt at self-improvement.
But the entirety of a craftsman’s professional development is contained within that gap between skill level and perfection. As this gap gets smaller and smaller, the craftsman’s focus becomes narrower and narrower.
Craftsmen are consumed by this gap. They talk about these ideals as if they’re affixed to every project—a piece of fruit hanging from the ceiling just out of reach. They challenge others to climb the walls and jump to try to close this gap too, and they employ hyperbole to justify the importance of seemingly mundane details and practices. “We need to test this remote edge case.” “Why haven’t you refactored this class?” Craftsmen are constantly working toward an ideal, and any ideal other than perfection is offensive. This hyperbole is not necessary, but it comes from a bias.
This bias creates a communication issue. Craftsmen are so narrowly focused on closing the gap between themselves and mastery that it becomes difficult to consider that others might not share this focus. They sound arrogant because their language is drawn from a different set of assumptions. But at a fundamental level, the craftsman’s assumptions are not derogatory. They are aspirational.
Craftsmen are slow.
Software craftsmen approach code as both the means and the ends. Accordingly, it’s not enough for a craftsman just to write a program. A craftsman crafts a program—devoting time and energy to reaching an ideal solution at every step in the process. To the untrained observer, this can look very pretentious. In a fast-paced, results-oriented team, a craftsman spends time refactoring working software. This can seem academic or self-indulgent in the face of a deadline. But the reason is both simple and practical.
As craftsmen, we’ve done enough practice to know that the cost of work has a non-linear relationship to its quality. If you don’t take advantage of an opportunity to refactor and increase the quality of your code early, it will take exponentially longer to refactor and add features later. Your code will have more bugs, and will be difficult to extend when your clients need added functionality the most.
It is not selfish to maintain this intensity and take this extra time. In fact, it is asserting our expertise. We know software, and we know that taking the time to produce code of a high quality from the beginning will pay major dividends for our clients later.
As craftsmen, we have a responsibility not to simply patch together an application that will only solve a problem in the short-term. We need to build something trustworthy and adaptable that can grow and evolve with the client’s changing needs. That takes time.
Craftsmen are dogmatic.
The asymptotic curve toward mastery is not the only curve that exists. Hackers and dabblers can gain experience in the industry, but their progress waxes and wanes with their focus. They take shortcuts when it’s convenient, and it leads to a slippery slope. The first time you neglect to write a test, you increase the likelihood that you’ll neglect to write a test in the future. You’ll develop poor habits, and your skills will slowly deteriorate.
This is the scariest outcome for craftsmen. Craftsmen always want to improve, to go on an upward trajectory. They want to close the gap between themselves and perfection, and avoiding the pitfalls of convenience is a primary motivation to keep craftsmen disciplined.
Craftsmen do not falter on their principles. They stick to their guns for the long haul. They push TDD to its Platonic ideal. They do this not because they are brainwashed automatons, but because their principles are built on observable facts that they have seen to be true. They remain disciplined because the danger of losing discipline is profound.
As craftsmen, we believe in the principle of strong opinions held weakly. Our opinions are derived directly from our experiences, and so we have strong reasons to believe that they are true. This knowledge and these opinions fill in the base of our learning curve—all of our skills and principles are the foundation for any progress we make going forward. To abandon these principles would be to take a step back on our path toward mastery, to insert a dip in our curve. If we lose discipline, we lose our way.
