A software craftsman is

Someone who aspires to quality.

Someone who considers the means as well as the ends. Alternatively, one who realises that everything has more than one outcome, and that as many of them as possible should be considered.

Someone who does not build unnecessary things.

Someone who does not dismiss things as unnecessary because they are not core to the experience from their perspective, or distant from their areas of expertise.

Someone who understands that every system has several different workflows, and does not optimise for one at the expense of the others without fully comprehending the costs and benefits.

Someone who continuously takes feedback into account, and is constantly improving the various feedback loops they have in place.

Someone who can deliver quickly and iterate upon previous work, taking feedback into the next iteration.

Someone who can respond quickly to unexpected change, and takes action to improve responsiveness whenever possible.

Someone who, while pragmatic enough that they continue to deliver, understands that less-than-stellar work will make them slower and more unresponsive over time.

Someone who respects opinions, but makes decisions based on facts. Where facts are not available, experimental evidence is necessary.

Someone who strives to learn more than they currently know, focusing on techniques, paradigms and philosophy rather than tools.

Someone who has good knowledge of their toolset, and is always learning more about how it can help them create.

Someone who recognises when it is more important to solve the problem with the tools available, and when it is more important to build new tools.

Someone who aims to learn more outside the scope of software development, in both technical areas (such as UI design or system administration) and business areas (especially those core to the purpose of the software) so that they can better understand what they are developing.

Someone who discusses potential solutions with others, in order to reach one that could not be achieved by any of them on their own.

Someone who recognises their deficiencies and weaknesses, seeking to either correct them, substitute them or delegate responsibility to someone who can deliver better in those areas.

Someone with the humility and open-mindedness to accept new ideas and fold them into their own, even when it means their previous work could be considered inadequate.

Someone who is aware that other solutions exist, and will weigh the benefits vs. the costs of changing course without becoming sentimental about previous work.

Someone who fits solutions to problems, rather than problems to solutions.

Someone who writes code for humans, not computers.

Someone who can evaluate code in their head, and when they cannot, strives to simplify it to the point where they can.

Someone who recognises that the definition of “simple” differs from person to person, and attempts to understand others’ definitions before coercing code to their own.

Someone who can communicate clearly and without bias, making sure to include all context in their communication, leaving as little as possible to interpretation or subjectivity.

Someone who recognises that discussion is no substitute for action.

Someone who recognises that disagreement is not an excuse to avoid discussion or debate.

Someone who can keep focused on the topic or work at hand, but does not dismiss or ignore new work because it is not currently relevant.

This list was created without order, though many of these qualities are related. Together, I believe they embody wisdom, open-mindedness, humility, drive, and many other traits I believe are crucial for good software development. Critically, unlike those traits, they are actionable: one can strive to achieve these things in a way that you cannot for something fuzzier, such as “open-mindedness”. From the other point of view, hiring or contracting a software a developer, one can (ideally) look for these traits irrespective of a person’s background, race, gender or any other discriminating factors.

When working in a team, I hope to see these qualities in my colleagues and co-workers.

Whenever I’m working on software, I hope to see these qualities in myself.

Thanks to Ben Summers for provoking this blog post, as well as providing very useful feedback.