Response to programming is not a craft
I have been trying to keep up with the discussion around Dan North’s post but being on holiday makes it difficult. Luckily the slowness to respond allows me to not write somethings because Dan has follow up with this. As he points out in his critical feedback section that correct definitions were not really the point. When I had started making some notes I felt that there were problems in his blog because there were disparate assertions but I there were at least these:
- Programming is not a craft.
- Programming requires skill
- Programming entry has been “democratised”
- Good programming requires expertise and experience
- Poor programming is still dominant
- Good programmers are not being rewarded
- Programmers still aren’t part of a profession
- Programming should be a means-to-an-end (value) and not an end-in-itself (the program)
- A programmer is not an artist
- Programmers that act as artists are a pain
- programming is best thought of as a trade
All good points. I’m pretty sure most of these are in Software Craftsmanship by Pete McBreen though So, I’m less worried about making a clear distinction between programming-as-craft or programming-as-trade? Why? Because I think it can be circumvented with arguments by Richard Sennett in The Craftsman. Firstly, Sennet does think that the computer programmer is potentially a craftsperson, albeit a contemporary one – “Developments in high technology reflect an ancient model for craftsmanship”. Laurie Taylor writes:
Craft, insists Sennett, is as important in modern society as it ever was in the medieval guilds and it is not simply to be found in the work of such traditional craftspeople as silversmiths, carpenters and potters. It can also be seen in the scientific laboratory (the equivalent of the old workshops) or in the work of software developers .. Craftsmanship for Sennett is “an enduring, basic human impulse, the desire to do a job well for its own sake.” But, as he shows, in today’s labour market, “doing good work is not a guarantee of good fortune. In work, as in politics, sharks and incompetents have no trouble succeeding.”
If you want a quick introduction on craftwork and skill with Sennett there is an interview with him here.
Who is a craftsperson?
In his book, he defines the craftsperson based on five aspects:
- Manual skills to produce things
- To do things for their own sake
- A level of freedom to experiment
- Reward of competence
- Within the context of a community to meet standards
So, really, do I use manual skills to produce things? How manual is typing really? I woodwork and play instruments and have a sense that the manual skills typing requires is similar both similar and different. Touch typing requires practice and to be able to anticipate code while typing tends to require me to not need to be thinking about typing at the same time. But, I don’t have to be able to touch type to be a skilled programmer – I might indeed not even need to type if I can do entry in another way. So typing is probably different from being able to feel the grain of wood while planing or releasing keys on a instrument. Sennett argument is far more subtle. He argues that the hand informs the work of the mind and that advanced hand technique might inform technical skills. Under a theme of tempo and anticipation, you should not be overly conscious of your hands as you loose the insight of anticipation. If you are interested in all this there is a wonderful description in the David Sudnow’s, Ways of the Hand, as he describes learning jazz piano.
On being troubled …
Then comes the next three items that in the world of line-of-business applications get more difficult. Personally, I find that can satisfy these in my projects. Yet, I have had many (and I worked for NZ largest software house) who argued you couldn’t. Working within that environment left me troubled partly because I found I was working on projects that didn’t satisfy the last item. Sennett has argued that the contemporary craftsperson is likely to be troubled and in three ways key ways:
Developments in high technology reflect an ancient model for craftsmanship, the reality on the ground is that people who aspire to being good craftsmen are depressed ignored, or misunderstood by social institutions. These ills are complicated because few institutions set out to produce unhappy workers. People seek refuge in inwardness when material engagement proves empty; mental anticipation is privileged above concrete encounter; standards of quality in work separate design from execution
Some notes here are:
- Wary of ideas that skills are innate
- They are practiced and repeated
- Skill development is based on how repetition is organised
So the problem in project-based work is developing skills outside the immediate task that would in fact help inside it – TDD is good example of this (of many).
Conflicting measures of quality: correctness and functionality
What do we mean by good-quality work? One is how something should be done, the other is getting it to work. This is a difference between correctness and functionality. Ideally, there should be no conflict. In the real world, there is. Often we subscribe to a standard of correctness that is rarely if ever reached. We might alternatively work according to the standard of what is possible, just good enough – but this can be a recipe for frustration. The desire to do good work is seldom satisfied by just getting by.
It seems to me that Sennett covers a lot of the bases found in the posts around the place. There’s also a wonder section of developing skills. I would take the time to read and digest this piece of work. It is far more insightful than say the Dreyfus model of skill acquisition – which has anyone remembered Dreyfus himself said was merely anecdotal?