,
25 tweets,
5 min read
Read on Twitter
This is a great idea: . Before I was a programmer I use to do a bit of odd-job carpentry, so I'm going to chime in with my take based on my experiences in that field.
When you're outside an area of expertise looking in, it can often seem monolithic and uniform, but when you're an insider you quickly realize that there are many different subcommunities, each with different specialties and different approaches. They sometimes hate each other :)
We know this is true for programming, so why shouldn't we expect this is true for everything else too? In fact, a good clue that someone doesn't have any experience in a certain area is that they radically over-simplify things. Experienced people never think things are simple.😀 
There's the same kind of complexity in the world of carpentry of course. In the following tweets I've got three examples (from my personal experience) for things that can all be called "carpentry" but need radically different approaches.
Example 1: I worked building kitchen cabinets for a while. To use a programming analogy, there is a clear spec and industry agreement on interop standards. It's easy to be productive. Once you've set up, you can cut lots of pieces at the same time without adjusting the tooling.👍
In the contractor business, it's all about cost and efficiency. You need to realize you're not making fine furniture, you're making something that might well be ripped out when the house is sold. Close collaboration with experts in other areas (plumbers, electricians) is vital.
Example 2: I also worked renovating a 400 year old cottage. We had to replace a massive old oak joist. In this case, nothing was square, nothing was even, so the replacement (with pegged tenons) had be cut to fit by trial and error, which took a painfully long time.
Sourcing the right wood for the replacement was very important too. No off-the-shelf quick-grown lumber from the yard. It reminds me of this story:
atlasobscura.com/places/oak-bea…
atlasobscura.com/places/oak-bea…
So this case, what's important is not speed, it's about being sensitive to the history of the structure. We were doing something carefully, because we wanted the replacement to last hundreds of years just like the original did. (Insert comment about legacy systems here...)
Different domains, different skills. If I had been a perfectionist at the kitchen cabinet job, I would have rightly been fired.
But if I had brought the cost and efficiency mentality to the renovation job, that would have been very sad.
But if I had brought the cost and efficiency mentality to the renovation job, that would have been very sad.
Example 3: I also worked as a stage carpenter, making sets. This is completely different again. You have to enjoy chaos! Deadlines, specs changing constantly, long hours. It's all about looks rather than substance. Things are literally just stapled together.
In fact, a solid foundation is actually a hindrance. I've seen a flat (panel) sawn right down the middle and fixed up again in minutes. You *want* the wood and the supporting structure to be thin so that you can do this kind of thing! (Insert comment about Agile and BDUF here...)
So "quality work" means very different things in these three areas. And the skills required are also different too. Different technical skills, different social skills, different admin skills. Bringing the wrong skillset and wrong attitude to a job wastes everybody's time.
I guess this is why I'm not a fan of "software craftsmanship" -- it implies that the same approach is valid everywhere.
A Bic pen is not any less well crafted than a Montblanc pen. They're both quality pens within their own context.
A Bic pen is not any less well crafted than a Montblanc pen. They're both quality pens within their own context.
So, to go back to the software comparison. Software is a very very very broad field and the subfields often have very little in common.
The skills/attitudes needed to knock together a brochure-ware website in PHP are completely different from those needed to build Google search, which are different again from those needed to build safety-critical aerospace software, or encryption libraries, or embedded systems
I'm sad when I see people trying to force all software development practices into a single square hole ("More craftsmanship!", "More engineering!", "More category theory!") because it doesn't recognize the wonderful diversity we have.
Ok, that's the end of the rant! Thanks for listening!
Ok, not quite done! I have a few more things to add.
We have a really terrible tendency to want to rank things. We think a Montblanc pen is "better" than a Bic. An old house built from oak beams is "better" than a flimsy set. But I disagree -- they're just different. Different requirements. Different constraints.
Yes, it would be irresponsible to build a house with luan and 1x3, but it would be equally irresponsible to build a stage set with 6" seasoned oak beams. 😬
Similarly, for safety-critical software, I would expect you to use formal methods or similar, and to work from a detailed spec. It would be irresponsible not to.
But using formal methods and a 200 page spec for a personal website would be stupid, and I would deeply distrust the competence of any programmer who wanted to do that. Using formal methods is not always "better" than not using them.
Really, these comments are obvious and should not need saying. Yet there are some people who insist that it is "unprofessional" if you don't use TDD, or static types, or continuous deployment, or whatever. Yes, these are very useful tools, but not everywhere, every time.
Software development seems to be particularly susceptible to cargo-culting for some reason. We have a trillion dollar industry, and yet we have a miniscule amount of hard evidence on what actually works. So until we do, let's be open minded and listen to each other. 🙏
