Craftsmanship Digest #2

If you like (or don’t like) what you see, let me know in the comments. If you have a resource you think would be a good candidate for one of these digest posts, again feel free to share via comments.

Five Years of Raising the Bar (~3 mins)

Doug provides a nice reflection of four areas where software craftsmanship is focused: well-crafted software, steadily adding value, a community of professionals, and productive partnerships.

The Craftsmen Have it Right: Defining Software Quackery (~9 mins)

Eric responds to Alan Stevens’ commentary on the software craftsmanship movement. Eric mentions that although “craftsman” is an incomplete metaphor, there are tenants of the notion that work: attempting to raise the bar.

A Spectrum of Trust (~6 mins)

Uncle Bob expands on his concept of a foreman for agile teams. He states, “The goal is to create a high functioning agile team in which everyone shares the same values.” At the time this article posted, Twitter was pretty active about not pigeonholing developers by roles; another concept was a gardener. Leon Gersing (a.k.a. @rubybuddha) had some opinions as well.

Good and Bad Technical Debt (and how TDD helps) (~9 mins)

This post presents a simple explanation (with pictures, too!) of technical debt and how it accumulates. Not all debt is bad; the important part is to be aware of it and know how to manage it when the time comes. The article describes how TDD along with some other techniques can keep technical debt in check.

We Are Principled – 11th Edition (~6 mins)

As an employee of 8th Light (which with Uncle Bob at the helm is steeped in the craftsmanship mentality), Rick reflects on some of the principles he follows: collectively reducing stress, having domain knowledge, being a rubber duck, and in general respecting others.

How to Debug Small Programs (~5 mins)

Eric states that Stack Overflow’s job is not to debug your code. Instead he proposes some tips to make things easier: turn on compiler warnings, obtain a rubber duck (see the previous post), break things into smaller units, write specs for your units, define pre-/post-conditions, write test cases, and use a debugger.


Leave A Reply

You must be logged in to post a comment.