I've always enjoyed the gems that people mine from his blog.<p>I'm big on Quality. Damn near <i>obsessive</i> about it.<p>I worked for a company that was renown for Quality. They were (and will be, for a while), one of those brands that is basically synonymous for "Quality."<p>They got there by a combination of <i>really</i> heavy-duty, enforced process, combined with some awesome "tribal knowledge." They have been doing it for over a century.<p>But it was not a good fit for software development (they make hardware). Way too inflexible.<p>Since leaving that company, I've been trying out some ideas that I had, as I worked there. For the most part, these ideas have been working -quite well; but I haven't really had a chance to scale them.<p>But software quality, these days, sucks like a supermassive, galaxy-core, singularity. It's reached the point where our entire culture is acclimated to crap software, and we even punish efforts to improve it.<p>Something needs to be done, and I've found that small, commonsense habits can go a long way towards that.<p>If we watch a craftsman at work, we will see them do lots of little things, that we barely notice (and that they, themselves, barely notice, as they are habit). These little things are what makes their work "Quality."<p>When they have an apprentice, they are forced to inventory their habits, and articulate them. That's one reason why martial arts schools make their senior belts train junior belts. It's also why I think that today's engineering culture of "24 months, max" at corporations is pretty corrosive to Quality.<p>I've found that writing my code, as if I am going to be using it to train someone else, and doing it long enough to develop Quality habits, helps me to do a better job on it.