Software Craftsmanship Ethics

Source: Doug Bradbury, Dave Hoover, Robert Martin, cast of dozens

This is the outgrowth of a conversation among Doug Bradbury and a number of Craftsman Manifesto signers. The goal of the collaboration was to come up with a statement of the Ethics of Software Craftmanship. In the course of the conversation, one of our participants suggested the pillars shown here (the brainchild of Jason Gorman).

The long form is quite beautiful, and presented here in entirety as an explanation of the four points above:

We consider it our responsibility to gain the trust of the businesses we serve; therefore, we take our customer's problems as seriously as they do and stake our reputation on the quality of the work we produc.

We consider it our responsibility to write code that is defect-free, proven, readable, understandable and malleable; therefore, we follow our chosen practices meticulously even under pressure and practice our techniques regularly.

We consider it our responsibility to hone our craft in pursuit of mastery; therefore, we continuously explore new technologies and read and study the work of other craftsmen.

We consider it our responsibility to perpetuate the craft of Software; therefore, we enlist apprentices to learn it and actively engage other craftsmen in dialogue and practice.

My reference was the Software Craftsman's Ethics talk. When the Care/Practice/Learn/Share thing came up, it was on the insistence of Adewale Oshineye (and accepted, I think, unanimously). I don't think there was any attempt to cut Jason out, but rather excitement over the idea. In the email, we didn't talk attribution and so I assumed it had originated there.

I see that Jason's email was much earlier than the craftsman's ethics discussion but was well past the point that I gave up on keeping up with the craftsmen email talk. I think that makes it my fault for not doing the research. Apologies to Jason Gorman, and this quotation from the email referenced above:

* We care about the quality of the work we do. It should be as good as we're capable of making it.

* We learn from our mistakes, we learn from the examples set by others. We learn from books and blogs and webinars, from magic beans and electric parsnips. When we're exposed to good examples, we learn better. So it's important to have good influences. If your guitar idol is Al Di Meola, you'll probably turn out to be a more capable playerthan if you followed Pete Doherty.

* We share what we've learned. That's the other side of the learning coin. Who sets the examples? Who writes the blogs, and creates the screen captures and dos the voodoo on the magic beans? We do, right? We are all simultaneously masters and apprentices, teachers andstudents, mentors and mentored, coaches and coachees.

* Most importantly - and this defines the whole movement as far as I'm concerned - we learn by doing. We PRACTICE. Continously. Like anathlete or a pianist or a circus clown or a lion tamer, we now that what we have to know and apply is far more than can be applied consciously. We must internalise our knowledge and build our "software development muscles" and the necessary reflexes and muscle memoryneeded to be a productive programmer. This is where I think we have been going wrong all these years; we've been treating software development as an entirely intellectual pursuit, one you can master(there's that word that's going to get us into trouble!) by reading books or watching other people do it. Which is hogwash. You can no more master a skill like refactoring by reading a book on it than you can master riding a bicycle by reading the manual. It takes practice: lots and lots of practice. Good practice. Focused practice. Measuredpractice.