Code as Craft
To win a race, the swiftness of a dart
Availeth not without a timely start.
Etsy's engineering blog "Code as Craft" can easily be considered one of the best ones in the industry.
In their definition of "craftsmanship", they make this long quote from The Pragmatic Programmer:
The construction of software should be an engineering discipline. However, this doesn’t preclude individual craftsmanship. Think about the large cathedrals built in Europe during the Middle Ages. Each took thousands of person-years of effort, spread over many decades. Lessons learned were passed down to the next set of builders, who advanced the state of structural engineering with their accomplishments. But the carpenters, stonecutters, carvers, and glass workers were all craftspeople, interpreting the engineering requirements to produce a whole that transcended the purely mechanical side of the construction. It was their belief in their individual contributions that sustained the projects: We who cut mere stones must always be envisioning cathedrals. (Quarry worker’s creed).
There are two parts about craftsmanship: one that is intrinsic, and one that is extrinsic.
The extrinsic part is perhaps the most obvious one: craftspeople think holistically about what they're building. In some sense, what they aim to accomplish is much bigger than their work. A great woodworker experiences empathy about her customer and aspires to build something that will delight the end-user. They not only support a use case, but go much further and let the produced artifact transcends it. Well-crafted code not only fixes a problem, it fixes it elegantly. It does not show any rough patch and feels a natural solution. The consequence of that is when a problem is not well-defined, or when the timeline set to fix it is not feasible, engineers should push back - or at least openly share their concerns, just like a good woodworker would do. Nobody would ever ask a woodworker to take shortcuts when he's building the house's framework.
The intrinsic part is about taking pride in one's work and reflecting about it. It's about sharpening one's tools and adding new ones. A great woodworker would talk for hours about his tools. It's highly probable that his workshop will be tidy, following the 5S methodology (more about that below). There's no reason software engineers should feel differently. On the contrary, they should always be learning, and a great way to learn is to strive for code quality. When you optimize for speed, you usually don't take time to learn about your tools and end up misusing them. In the long term, this strategy will ultimately backfire.
Engineers who take the time to learn about tools, who take time to write testable & quality code, who take time to carefully think about the architecture of a service or of an implementation (e.g. following design patterns) will perhaps be a bit slower in the short term, but this will pay out ten times in the long term (in quality but also in speed). Striving for quality in every project, in every task, even mundane (e.g. by automating a test that could totally be done manually) will enable you to reach the same amount of quality much faster. Always caring about quality enables continuous improvement: it might take one hour to learn about how to properly use a complex but powerful feature of a Python library, but the next time you'll have 1- probably a much more reliable and fast solution 2- trained your brain to be constantly learning. Our industry is moving so fast that this is in my opinion the only durable strategy.
Craftsmanship is ultimately about the worker as a person. Craftspeople are those who learn and have fun doing it!
Here are the 5S (seiri, seiton, seiso, seiketsu, and shitsuke) applied to software engineering:
- Sorting: remove code that is never run.
- Set in order: streamline deployment and management through scripts and automation.
- Systematic cleaning: remove all TODOs, FIXMEs and temporary code.
- Standardising: remove hacks by improving patterns, abstractions and architecture.
- Sustaining: use continuous integration tools to prevent backsliding.
(there's a similar take about 5S applied to software development in this article)
Pictures from RaidersLight (CC BY-NC-SA) and Alan Cleaver (CC BY)