Pete McBreen's Software Craftsmanship: The New Imperative (2002). Most of the book is about the consequences of distinguishing between "software engineering" (defined as armies of programmers going down a waterfall) and "software craftsmanship" (defined as small teams working incrementally). He runs deep with the craftsman metaphor, taking seriously how to make real the "apprentice" and "journeyman" stages in a software developer's career. One interesting thread is that he points out how "best practices" are firmly a creation of the software engineering side of his binary, and do not satisfy craftspeople's very different trade-offs. Some by nature will wind around on their own path, custom-fitting each architectural decision to their preferences and the needs of the specific project. There is overlap with our discussion of a month ago, exploring @Jack Rusher's ontology of [programming, computer science, software engineering]. It seems useful to me to further distinguish the "strong S.E." that Jack and McBreen use as definitional from the "soft S.E." which we all seem to use colloquially to mean all manner of techniques for making an application error-resistant. The work of the latter may not be intellectually engaging or novel but it lacks the qualities which make strong SE distasteful: centralization of power, treating developers interchangeably, the urge towards monoculture, a cultural belief in "training" instead of learning.

This is toward the top of my reading list for new developers on my team.