Software Craftsmanship – Letters from the Road No. 2

Dear Craftsman,

It’s been a brutal month for me. I’ve been in the business the better part of two decades, but this has been the hardest few weeks I’ve had since I was a teenager waiting tables. Angelinos are prone to theatrics; I’m not — this is for real. And that’s my excuse for my radio silence here.

I also haven’t seen much come across my radar worth reporting (not to mention that I haven’t had time to figure out what I want for lunch let alone have an original thought). But I did come across another email list you should consider subscribing to from a craftsmanship Meetup organizer in France. Looks like it’s a new group and a new list, kinda like mine. I hope his turns into something (and ours too).

One of the links in his newsletter is to Trey Stout’s recent Medium, Engineering Principles. Stout’s an engineering manager out in NYC… a herder of nerds like I find myself today. Engineering Principles includes an eleven point guide to things that seem to have worked for him. Of immediate interest to you, my dear craftsman, is that he encourages his engineers to “be a craftsman” (#8) and defines craftsmanship thusly:

[a] product’s quality is only as good as its weakest part. This can manifest itself as well documented modules, open-sourcing our tools, or just giving lunch-talks on things you’ve made.

Personally, I think his comment on craftsmanship is probably his weakest point. That said, I think you should review his post because his other points go to the kind of critical thinking that might be the genesis of craftsmanship among individual developers — especially people who want to lead and develop craftsmen, like me.

I’m deeply envious of his list — why can’t I come up with a list like that? But of course I can. So can you. We’re both smart enough to write code and deal with the precisions required by the machine. We can think critically if we try.

But therein may lay the problem: maybe dealing with the pedantry and quirks of the language we’re working in, the ill-documented frameworks, someone else’s crappy API, the buggy IDEs, the soul-sucking enterprise policies, the oppressive meetings, and the broken ice machine in the break room cause the critical thinking cell of developers’ brains to get beaten out of too many enterprise developers. I’ve pulled the victim card on this too many times myself, but now that culture is on my job description my bosses took my victim card away from me. I don’t think I get to pull yours by proxy.

These days, I think that’s why craftsmanship in software is such a valuable thing to me. Somehow, I imagine true craftsmen rise above the frey, the bullshit that is day-to-day working life, and they think deeply about their craft. That’s why I aspire to it, and I aspire to figure out how to give my teams the environment they need to aspire to it.

I hope you do too.

Leave a Reply

Your email address will not be published. Required fields are marked *