Wednesday, 10 December 2008

Inside the Mind of a Craftsman

I know some really skilled software developers who are not good craftsman. I want to understand why.

My definition of a good craftsman is someone I want to work with on a daily basis. It helps if they can write great software but that isn’t the primary attribute I’m looking for. Here are some characteristics of good software craftsmen:
  • They do what they promise, and they don’t promise what they aren’t sure they can do. Some people take on way too many tasks and then fail to deliver properly on any of them. One reason someone takes on too much is because they are scared to say no, but a more worrying reason – common among poor craftsmen – is that they are very bad at judging how long things will take.
  • They are well organized. Some people are naturally good at keeping things straight, and these people inspire confidence. Well-organized people can take on parallel tasks without compromising the outcome. Poorly organized people are sometimes good craftsmen but only if they have recognised their lack of organization and dealt with it by taking on only one task at a time.
  • They can tell me why they are doing things in a particular way. Donald Schön maintained in his landmark 1983 book The Reflective Practitioner that the best professionals know more than they can put into words. Well, he may be right, but software developers who can’t explain why they are doing something, or at least take the time and trouble to consider the reason, scare me.
  • They are very particular about the detail. There may be exceptions, but it’s hard to imagine someone being too anal-retentive to be suited to a career in software. Machines are very unforgiving to minor lapses in accuracy and a good craftsman treats them with the respect they deserve. The real skill, though, is in understanding which things require detailed attention and which don’t.
  • They are disciplined. If there’s a defined process they always follow it; if there’s not they make one up and follow that. Many of the processes we follow as software developers are not written down but that doesn’t make them less important. A good craftsman respects the processes because he or she knows they are there for good reason. Conversely, a good craftsman won’t put up with poor processes but will tirelessly seek to improve them.
  • They aren’t afraid to say they don’t know, and are always willing to learn. Admitting you don’t know something requires maturity, and maturity is a characteristic of good craftsmen.
  • They work at a pace I can stand. During my career I’ve met a handful of people who I found impossible to work with for long because their minds operate at a much faster pace than mine. These have generally been interesting, brilliant and likeable folk, but never have they been team players: other people just can’t keep up. These people often have difficulty answering questions about why they are doing something because they have already moved on to the next task and are now devoting their not inconsiderable intellect to solving that. For me, people who progress too slowly are nearly as problematic, even if they are skilled at getting a good end result. I’m not very patient, but I am working on it.
  • They can appreciate the implications of their work at different levels of abstraction. Good craftsmen always have in mind the end goal, the big picture, even when working on the tiniest of details. The implication of this, of course, is that good craftsmen have a deep understanding of abstraction as a tool.
  • They invest time in their tools. All good craftsmen know that they need tools they understand and can trust. So good craftsmen never cut corners on tools – they use they best they can get, and take the time and effort to learn how to use them properly.
My main point here is that it’s possible to have complete mastery of the technology, to know and use all the latest design techniques, and still be a poor craftsman.

Can you learn to be a good craftsman? I’d argue that a good number of the characteristics on my list can’t be learnt, at least not once you’re an adult. The obvious conclusion, then, is that some people can never be good craftsman.

So what can we say about people who have these characteristics? First, it’s likely they have been developing software a fair while – universities don’t turn out craftsmen. Second, they have reasonable inter-personal communication skills. Lastly, and most importantly, they care about their work. You never met a craftsman who didn’t care.

3 comments:

keithb said...

Right now there are several discussions of software craftsmanship (and "mastery" thereof) floating around that part of the intertubes to which I pay attention.

What strikes me as interesting about this one is that it doesn't (as some do) focus on the properties of the work products that the "mast craftsman" produces. Nor does it focus primarily on the technical skill and knowledge of the craftsman, but instead on the behaviour and attitude of the craftsman. I think there's something in that.

Raoul Duke said...

imho, not that anybody asked, i particularly agree with the "you have to be able to explain it" thing. to claim that it is too advanced or subconscious to explain to another person makes me think they are going to miss opportunities to refine or change their game for the better.

Mark Dalgarno said...

I'm with you and Keith that it's more about attitude and behaviour rather than technical skills.

I think a good craftsman also creates their own tools where they recognise limitations in existing tools. This is simialr to creating a new process when the current one is defiicient. Understanding when and when not to do this also signals some level of mastery.

Michael Feathers said something at SPA2008 that stuck with me. He basically said that people who took part in events like SPA ended up being spat out of their organisations - they were 'improvers' (my word not his) and eventually would get frustrated with the slow pace of improvement at their workplace. If we look at your definition we can perhaps see some reasons why this might be the case.