3 ms·

Taking ownership of and responsibility for one's own work, taking pride in it, and seeing the whole project through to completion (rather than being a cog on an

Taking ownership of and responsibility for one's own work, taking pride in it, and seeing the whole project through to completion (rather than being a cog on an assembly line, to mix metaphors) are certainly craftsmanship values. But for code, "craftsmanship" is problematic. Not just that it changes so quickly (compared with traditional crafts), that ideal skills don't have time to be defined, let alone mastered. This is caused by the malleable, abstract thought-stuff of code, and it occurs even within the work of the individual coder: as soon as you master something, it should be abstracted into a library or framework - a product. This puts the coder at a higher level, which is a different level, and therefore not yet mastered. Such factoring opportunities are far rarer in traditional, physical crafts. Productization obsoletes craftsmanship. Of course, not every task is sufficiently self-contained to be usefully factored out - instead, the code itself is pretty much the best "abstraction" you can do. But can these ad hoc tasks really be mastered either? > ‘I didn’t know how to do x, so I just had to figure it out.’ This is what I regularly hear from successful founders, whereas ‘I couldn’t find someone to do X, so I had to reconsider whether to pursue it at all’ is a common refrain from unsuccessful founders. Grit, resourcefulness, improvisation - great! But "figuring it out" is much closer to hacking a solution than achieving craftsmanship-like mastery...

gurkendoktor 9y ago
> This is caused by the malleable, abstract thought-stuff of code, and it occurs even within the work of the individual coder: as soon as you master something, it should be abstracted into a library or framework - a product. You can also turn this around: Maybe software craftsmanship is not about writing great code (for the reasons you mentioned; the article also doesn't phrase it that way), but about skillfully using existing tools. Peek into the open source libraries you use, disassemble the closed-source ones, take your time to really understand that occasional bug. There are many tools that rarely change (extreme examples: Unix, RDBMS, programming languages), and grokking them is not something that can be productized. Yet I see few people/businesses making that investment; it's easier in the short term to treat everything as a black box and add more abstraction glue, and that's what I see many people/businesses do.
- hyperpallium 9y ago
  Yes, there are meta-skills of tool use. Another enduring eg: vi. Muscle-memory investment is retained - very like tool-use in a physical craft. I think git will last forever(!) too. Still seems more like a journey man or handyman than craftsmanship, but maybe that's not fair of me. I agree there is deep craft in understanding tools. Hmmm, maybe developing/maintaining those enduring tools is even closer to craftsmanship? Unfortunately, enduring codebases get worse over time by conglomeration! The antithesis of craftsmanship. People who have written the same kind of enduring tool several times (from scratch) would probably be the epitome of software craftsmanship. e.g. plan 9 and go. But, gluing black-boxes is more productive.

gurkendoktor 9y ago

> This is caused by the malleable, abstract thought-stuff of code, and it occurs even within the work of the individual coder: as soon as you master something, it should be abstracted into a library or framework - a product. You can also turn this around: Maybe software craftsmanship is not about writing great code (for the reasons you mentioned; the article also doesn't phrase it that way), but about skillfully using existing tools. Peek into the open source libraries you use, disassemble the closed-source ones, take your time to really understand that occasional bug. There are many tools that rarely change (extreme examples: Unix, RDBMS, programming languages), and grokking them is not something that can be productized. Yet I see few people/businesses making that investment; it's easier in the short term to treat everything as a black box and add more abstraction glue, and that's what I see many people/businesses do.

hyperpallium 9y ago
Yes, there are meta-skills of tool use. Another enduring eg: vi. Muscle-memory investment is retained - very like tool-use in a physical craft. I think git will last forever(!) too. Still seems more like a journey man or handyman than craftsmanship, but maybe that's not fair of me. I agree there is deep craft in understanding tools. Hmmm, maybe developing/maintaining those enduring tools is even closer to craftsmanship? Unfortunately, enduring codebases get worse over time by conglomeration! The antithesis of craftsmanship. People who have written the same kind of enduring tool several times (from scratch) would probably be the epitome of software craftsmanship. e.g. plan 9 and go. But, gluing black-boxes is more productive.