In “compare, a chisel and a plane”,  Doug Stowe writes:

And yet, it is risk, not knowing the outcome, working against the odds, putting forth effort, and accomplishing things that express mindfulness, effort and skill, that make life and the things we make most meaningful. And so, what this boils down to is that at least some good measure of what we do should be done the hard way. Choose your tools wisely, that they allow for the development of your skill.

In “skill and toolery”, he says:

These simple charts may help to explain why so many wood workers like to work with hand tools. Skill and attention are matters that create feelings of self-worth and accomplishment. They are the soft side of harsh reality, and the human component that compels engagement in physical and cultural reality.

These things speak to my heart. If I’m good at a few things, it is because of the joy that the craft of making them has brought to me. This applies to all the things I may do moderately well.

If I express software development ideas nicely once in a while, it is as a result of having expressed them hundreds of times in different ways. Some of those ways have worked well, some incredibly poorly. (I apologize to those of you who have had to read so many of them, and offer thanks for your help in the occasional success.)

If I have the ability to look at most any design, most any code, and see how to make it better, it is because I’ve looked at so many bad designs, so much poor code, that needed improvement, and have worked with them to try to make them better. I hasten to add that most of these unsavory collations were my own.

A small lesson for me ...

Last week, Chet and I taught a TDD/Refactoring class. We also taught two Agile Introductions, a CSM, a Story Workshop, and a Partridge in a Pear Tree, but the TDD/Refactoring one is on my mind just now. In that class, we demonstrated how we do TDD/Refactoring.

Naturally, duplication was one of the first smells we encountered, and removing it was one of the first refactorings we applied. We did that with Extract Method, and we used the built-in tool. As I think about it now, we’d probably do well to do the first few refactorings by hand. There are at least these reasons:

  1. First, the tools work instantaneously and as if by magic, and the audience almost certainly cannot follow what happens as code disappears from one place, replaced by something different, and then appears somewhere else. I know that when I watch coding examples, those quick transforms escape me, and I generally know what to look for.
  2. Second, what's important about this refactoring, and any refactoring, is what's going on in our mind ... and that is best learned by looking at what we do with our hands.  We perceive the code transformation better if we move the code around ourselves. We learn it better.
  3. Third, real-world refactorings can be aided by tools but the tools won't do them, they'll just do the steps. We learn to proceed in steps, not by pushing the magic button, but by proceeding in steps.

Henceforth, when we do these demonstrations, I’ll make a point of doing things by hand for a while. The magic tools, as Doug Stowe suggests, may decrease risk, but they also decrease our skill.

... and a question for us all

Which of our tools are increasing our skill, and which ones are standing in the way? Which of our tools are bringing joy to our lives, and which ones are standing in our way?