Excuse the strong language, but I can’t stand snobbish, deceitful drivel like this. The article attempts to make the explicit point that programming is not a craft (because, apparently, the author thinks they have a monopoly on what it means for something to be a craft). But its subtext is far more sinister: it not-so-subtly weds the idea of craftsmanship to negative qualities like “big ego”:
So here’s my concern with the idea of Software Craftsmanship. It’s at risk of letting programmers’ egos run riot. And when that happens… well, the last time they went really nuts we got Web Services, before that J2EE. They convinced the British government that they wanted an uber-database to store Everything Ever About Everyone. You see where I’m going?
Blatantly irrelevant analogies:
Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.)
Programming isn’t plumbing and plumbing isn’t programming. What one does has no bearing on the other.
Well it seems to me the most succesful programmers I’ve encountered don’t craft software
Which is clearly supposed to read as, “Successful programmers don’t craft software.” I’m not putting words in the author’s mouth. The entire point of the article is to seemingly generalize their own opinions to programming as a whole.
Do I need to demonstrate any kind of skill? No. Any specific credentials? No. Any kind of experience working in the field? Nope (and as the Pragmatic Programmers are happy to remind you, ten years experience is very different from one year repeated ten times). In fact, all I have to do to associate myself with Software Craftsmanship movement is to fill in my name on the website. Woohoo!
As if acknowledging craftsmanship necessarily implies throwing out every other indicator. Really? The subtext with this nonsense is that people that see programming as a craft will produce lower quality code. The author even bemoans the loss of good programmers to the craft:
Software practitioners – especially, ironically, the good ones – often lose sight of this. They fall in love with the software itself and start thinking of themselves as craftsmen of software.
Unbelievably, despite the fact that programming isn’t a “proper” profession (the author’s words), the author has still somehow managed to identify good programmers from bad programmers. I know I’ve certainly never needed to see someone else’s certificate, nor have I ever needed the approval of some “Software Craftsmanship Council” to tell if a programmer was a real craftsmen or not.
I’ll never forget my programming languages course. On the first day, the professor went around the room and asked us to name some properties of programs. You had the usual suspects: “correct,” “fast”, “functional”, “object oriented”, “size” and so on. I was the only one who said “beauty.”
Donald Knuth has my back:
We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better. Therefore we can be glad that people who lecture at computer conferences speak of the state of the Art.
You can try to impose as many pre-conceived judgments on me as you want (“losing sight of the utility of software” or my giant “ego”), but I’m never going to stop seeing programming as a craft. I always have and I always will.
Fantastic quote by Donald Knuth!
A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better.
To me, this is the biggest thing that separates a software engineering from many other engineering professions.
It’s from his Turing Award lecture. One of my favorite reads: http://www.csi-india.org/c/document_library/get_file?uuid=ca21663f-8d86-4e76-a748-05e013406a53&groupId=47898
Thanks for this. The article bothered me, but I didn’t feel able to explain why. As a “hook”, the author refers repeatedly to a disconnect between engineers and users, and, actually, that’s true - there are several such disconnects and they deserve individual attention. I suspect most readers will agree with that part. You correctly point out that the real thesis here doesn’t follow from it, and I agree with all your points.
I guess I’d not go so far as to call this “deceit”; I believe the author is sincere. Most people who have conflated different things like this are unaware they’ve done so. I’ll give you “snobbish” though. :)
You have me very curious - how did the professor and other students respond to “beauty”?
As a “hook”, the author refers repeatedly to a disconnect between engineers and users, and, actually, that’s true - there are several such disconnects and they deserve individual attention. I suspect most readers will agree with that part.
I guess I’d not go so far as to call this “deceit”; I believe the author is sincere. Most people who have conflated different things like this are unaware they’ve done so.
Also agreed. I could have been more charitable. Just got a bit riled up!
My professor paused and smiled, then moved on to the next student. It was one of those “first day of classes, let’s get the juices flowing” kind of thing. But that moment has stuck with me.
We actually became very good friends. I went on to TA that course a couple times, and it is one of the most enriching experiences I’ve ever had!
I like the idea of programming as craft but I liked that the article raised a number of issues involved with the craft conception - despite the unfortunate “slick consultant” tone.
The challenge is to engage in software craftsmanship in a fashion that makes a customer care about that craftsmanship.
The example of the plumber seems good. The average person understands that not everyone who can stop a leak does so with equal skill. The immateriality of software makes that understanding harder. How can it be communicated to people effectively?
While you’re right, I think his analogy here is apt, but it also misses the point. A good plumber would see a bad plumber’s jumble of pipes and think “That’s a fucking mess”, just like good/bad programmers do with code. And why do we think it’s a mess? The reason a jumble of pipes or a pile of spaghetti code is scary is because we’ve been trained to recognize these patterns and associate them with a broken plumbing system or broken software.
There’s a reason why highly skilled programmers think simple, elegant code is something to work towards, and that reason is because more often than not, it works.
Either way, I absolutely agree with you. And this article has some serious gaping holes.
Totally fair point! Agreed. :-)
burntsushi (If that is indeed their real name :) ) has made a point 25 folks, including me, agree with. But I would like to soften the language a bit and perhaps add my own version:
Giving the author a more charitable interpretation, we could perhaps think they are saying that software engineers should not put the beauty of their craft (sorry, trade profession) over its utility.
Like all things, there is a balance. It is true software has a function. So does the engine compartment of a car. But when we pop the hood, don’t we all get a thrill when we see a well designed engine layout? All the wires laid out neatly, not a cubic inch wasted. Don’t we feel a trans-dimensional kinship with the unseen designer when we find that they have left enough space for us to get our hands inside and undo the fuel filter valve without having to dismantle the rest of the engine?
Don’t we feel that the engineers who designed this beauty of a machine were happy people, who enjoyed their work and went that extra hour on the design board, thinking of us, thinking of beauty?
Software is the same thing. Not everyone pops the hood, but some do. And they tell other people. “These guys know their stuff! Look how well they did that!” And such news travels far.
Yes, that’s very much agreed as well. And actually, users who have bonded with a program tend to understand its architecture in a lot more detail than engineers might expect, even with no technical background. Because the data model is implicit in the capabilities, and because the performance characteristics are telling to someone who is taking a moment to try to understand why the task they just kicked off needs ten seconds instead of being instant. :)
burntsushi (If that is indeed their real name :) )
Funny story. I was giving a talk at the Boston Go meetup the other week, and I was introduced as “burnt sushi.” :P
Google knows my real name. It’s no secret!
(Oh dear. Urbandictionary appears to have a rather colorful interpretation of my nick. I can rest assured that my origins are pure: graffiti from the wall of a hotdog stand over a decade ago.)
I am sympathetic to the articles point, but don’t think it was well made. I personally think a more coherent argument against “Programming as a Craft” is Mike Acton’s CppCon Talk on Data-Oriented Design. A lot of his points in the talk directly apply to the negative things associated with self identified “software crafts(people)”.
The “Three Big Lies” and point 3 in particular seem very applicable to self-described “software crafts(people)”. They tend to radically overvalue code and see it only as an asset rather than liability. In the last 20 years of doing this, I have seen far more code I would label a liability than an asset.
The code isn’t the point, the data transformation is, all programs and parts of those programs exist to transform data. Sadly, I think software developers tend to fall into a defensive posture when people question them on the value of code, rather than being coherently reasonable about it.
This isn’t an “either-or” proposition. Just because I value programming as a craft doesn’t mean I don’t also have the capacity to reason about programs in terms of assets and liabilities. (For me, these things are connected!)
When someone says “I am a software crafts(person)” what I hear is “I am won’t actually help the team”. It was what – 2001 when Pete McBreen wrote “Software Craftsmanship” and since then, I have been actively avoiding (sometimes unsuccessfully) working with people silly enough (or arrogant enough) to apply such a label to themselves.
Honestly, it is exceptionally useful as a filter. “I am a software crafts(person)” is like the polar opposite of “I work on open-source, here is my github profile.” In the last decade or so, since that label really took root, I have yet to work with anyone that self-identified as a “software crafts(person)” that I wouldn’t consider outright toxic.
Obviously anecdotal, but in my experience they just don’t get anything done. That isn’t to say they aren’t working or doing stuff, it isn’t even saying they are lazy, just extremely inefficient. A friend of mine recently called them “small batch artisanal code generators, hand crafting with love (not skill).” They overvalue code and undervalue data (and shipping) so they get stuck in worrying about how it should be done rather than you know… doing it. Constantly building layers of premature abstraction. Always forgetting to future discount. Over-complicating and over-engineering the most straightforward of data transformation problems.
Honestly, it is exceptionally useful as a filter. “I am a software crafts(person)” is like the polar opposite of “I work on open-source, here is my github profile.”
Well, consider me your first counter example that these things are opposites. I’ve never self identified as “software crafts(person)” but I certainly view programming as a craft. And here’s my github. :-) https://github.com/BurntSushi
Honestly, I think you’re pontificating way too much. I get that you have your filters, and maybe people who like to loudly self identify often correlate with other negative qualities. But my only point here is that we should be afforded the opportunity to view code as an art, and not denigrated for it by being accused of having “big egos.”
Over-complicating and over-engineering the most straightforward of data transformation problems.
In my experience, the simplest and most straight-forward solutions to data transformation problems are also the most beautiful. Maybe you’ve just been burned by a few charlatans? I don’t know.
And here’s my github. :-) https://github.com/BurntSushi
Just curious, are you paid to do open source? You have a lot of weekday commits ;)
We have some Python stuff, but nothing hugely popular, and there’s still a big split internally between proprietary code and open source code. We’re still small. That said, yeah, there’s at least a few work related pushes to github on most days.
But when I get home I try to get a few hours of side-project time in, which is probably where the majority of my public activity comes from.
Ah ok, just asking because I have a couple side projects and don’t manage to get quite as much public activity as you do. But that may have been because I was working for myself until recently and so my work projects and side projects were basically the same, and I didn’t open-source my work projects.
I guess I’ll have to see if my activity increases over the next few months.
Programming is not a craft
You obviously haven’t seen me at work.