Software Craftsman

Craftsmanship is the quality that comes from creating with passion, care, and attention to detail. It is a quality that is honed, refined, and practiced over the course of a career.

Principles of Great Design: Craftsmanship, Richard Glover, 2010

An ancient Chinese proverb states the journey of a thousand miles begins with a single step. Malcom Gladwell in his book Outliers socialized the concept of the 10,000-hour rule. The over-simplified premise of this book is that it takes 10,000 hours of effort to become an expert. Gladwell’s book was based on research done by Anders Ericsson, a Swedish psychologist who specializes in the science of peak performance. However, in the article Malcolm Gladwell got us wrong: Our research was key to the 10,000-hour rule, but here’s what got oversimplified, Ericsson states that Gladwell misinterpreted his research. Ericsson’s premise is that it’s not the amount of time spent on an activity that makes an expert. It is the deliberate practice of a planned, arduous series of activities designed to improve skill in a particular domain, guided by well-informed feedback.

Software engineers who become craftsman employ deliberate practice as described by Ericsson. However, numerous engineers don’t understand this concept. I have often heard developers describe their years of experience as a reason why they should receive a promotion. However, it’s not the amount of time spent repeating similar tasks that make one an expert. It’s the deliberate practice of new skills that significantly improve one’s proficiency.

It is also the art of knowing what is beautiful, and caring enough to make it so. Problem-solving abilities don’t necessarily equate to craftsmanship. I’ve worked with two such engineers who were amazing problem-solvers. Whenever we had a significantly complex issue in an ambiguous problem space, we put them on it. However, their effectiveness was limited to prototypes. Their code was so sloppy that it wouldn’t be appropriate to call it production grade. Once they’d coded a prototype, it was necessary to hand it off to another engineer to craft the final solution. Both engineers were coached numerous times, but once they’d discovered a solution, they became extremely bored and didn’t have the passion or attention-to-detail to make the code beautiful.

It becomes quickly evident when working with an engineer who is a software craftsman. The signs are readily apparent and manifest themselves in the following ways.

• Well-thought design– solutions are grounded in solid design principles. It is not enough to just get something working. It must be maintainable, scalable, secure, extensible, resilient, robust, etc.
• Pragmatic implementations– solutions are elegant in their simplicity. They are neither over-engineered, nor under-engineered.
• Appropriate test coverage– good tests provide a craftsman peace-of-mind that the solution satisfies the acceptance criteria and that other engineers won’t bastardize the solution by failing to consider the original constraints under which the solution was crafted.
• Use of appropriate technologies and frameworks– a craftsman uses the most appropriate tool to accomplish the objective.
• Strict adherence to quality– cutting corners doesn’t exist in a craftsman’s vocabulary. Sub-optimal or sloppy implementations only create technical debt.
• Readable code– there’s no need to ask a craftsman what their code is doing. The intent is self-documenting and not obfuscated under the guise of cleverness.
• Enforces compliance– a craftsman becomes visibly upset when other engineers don’t follow the principles outlined in this list above.

Sample Interview Questions to Assess Software Craftsman

Show me the code you’ve written that you are the most proud of. It is impossible to hide the work of a craftsman. It comes thru in every aspect of their code. It’s neat, clean, organized, simple, well-tested, and well-designed. In short, it’s a work of art.

Related Posts

---

Do You Lead a Software Team?