I'm currently reading Schön's The Reflective Practitioner: How Professionals Think in Action. I plan a few summary posts.

Schön describes how practitioners' problem-solving method consists of poking at the problem with a partial solution, deciding what they think of its reaction, and deciding what to do next[1]. If satisfied with the reaction, they proceed further. If not, they regroup in a number of different ways.

This reminds me of software development in the style of the Mikado method or Corey's Haines' short-lived branches: you do some work, you think about it, you either commit/push or revert. As such, the following (p. 133) from Schön may be useful:

[The subjects of two case studies] act as though they were judging their reframing of the students' problems in terms of these questions:

  • Can I solve the problem I have set?
  • Do I like what I get when I solve this problem?
  • Have I made the situation coherent?
  • Have I made it congruent with my fundamental values and theories?
  • Have I kept inquiry moving?

I like these as something to think about before deciding whether today's work is code deserving of a commit:

  • Does it work?
  • Is it right according to a variety of standards, only some of which are easy to state? I like the words "coherent" and "congruent" for reasons that I hope to explain over the next few months.
  • Does the code as written open up new possibilities[1:1], or close them down? (The latter happens so often that I think it's worth calling out as something different than one of "a variety of standards".)

I do think these same questions are worth asking when the unit of work is larger, but they apply more obviously in the small.

  1. "Act always to increase the number of choices" - Heinz von Foerster. A catchy sound-bite, one with which I broadly agree, while understanding that limiting distracting choices is necessary for forward progress. ↩︎ ↩︎