A Checkin Checklist
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 next1. 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 possibilities2, 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.
"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. ↩