The Law of Unintended Patterns

For any matched pair of non-trivial examples
there exists (n == 1) pattern that the creator of the examples intended to highlight
but there also exist (1 < n <= infinity) unintended patterns that students will find.

It’s difficult to live-code programming examples… the conventions we use by habit often invite students to find the unintended patterns.

As an instructor, how do I get students to see the single pattern in which I’m interested, rather than the possibly infinite patterns that exist? Or, is that even the best goal? Should I, instead, be encouraging students to look beyond the first pattern they detect in order for them to appreciate the inherent complexity of interpretation?

3 thoughts on “The Law of Unintended Patterns”

  1. Yep, sounds like two steps are needed–one of generation, one of judgment (hey, just like SCIENCE–context of discovery, context of justification).

  2. Unfortunately, often (albeit not always) the “benefit” is adherence to best practices or language-specific idioms that, while reflecting what a seasoned programmer would do, may not offer functional or structural benefits in the constrained context of the example or exercise.

    I think the explicit generation of multiple interpretations at least brings to the surface the implicit thought processes of the expert, i.e., that the unintended patterns have been considered and excluded based on training (“there’s a well known solution to this…”), quick thinking (“here’s a clever little solution…”), or forward thinking (“I’m also going to need to…”). Generation and filtering of alternative approaches is a desirable habit of mind, yes?

  3. “Best goal” is relative to all sorts of things. If your goal is problem solving in programming (a subject I’m QUITE ignorant about), then frame the problem (if possible) so that identifying the “right” pattern pays off for them in a way that finding the others don’t. What’s the benefit of the intended pattern? Can you set them up to recognize that payoff?

    Or, let them generate all the non-intended patterns, and then ask them if they can identify what the intended one has that the non-intended ones do not.

Comments are closed.