When to detail step? Learning from young minds making things

Source: Hillebrand Steve, U.S. Fish and Wildlife Service via Wikimedia Commons

Source: Hillebrand Steve, U.S. Fish and Wildlife Service via Wikimedia Commons


At any time that we’re making something, there are the big picture goals of where we’re trying to get to and the smaller detailed “how-tos” of actually getting there.

But if we’re helping someone who is creatively learning, which of these (larger goals or how-to details?) should we emphasize? And how much should we directly spell out? What sorts of things might people best learn in the thick of action itself — based on their own observations or noticings of what helps them sidestep snags and stumbling blocks?

Here’s a compelling example of when to stand back and let incidental learning take the reins. It’s an excerpt from a blog post by Kartik Agaram about teaching computer programming to a young student:

“As the exercises he worked on became longer than a screen or two, though, he started noticing for himself that there was a problem: he was having a hard time explaining his solutions to me, or getting help when he got stuck. I’d often ask, “where is the matching counterpart to this bracket?” Or, “where does this loop begin?” Often he wouldn’t know either, and more than once figuring out the answer would also help figure out why his program wasn’t working. One fine day last week I showed up to a lesson and found him imitating my indentation.

I continued to ignore this and focus on the specific problem we were working on, but I’ve been finding myself increasingly reflecting on this one seemingly trivial evolution. Did the fact that he picked up indentation automatically suggest that it was in fact more important than I think? On reflection, I think the lesson is something else: my student magically managed to learn how to indent code, without learning a bunch of undesirable habits and heuristics:

That indentation is more than an incidental detail.

That good programming is about following a set of rules.

That aesthetics matter in code beyond the behavior being implemented.

Basically, my student now indents just like any other programmer (to the extent that anybody should care about it) but knows why he does so, the concrete benefit he derives from it. He is open to changing his habits in the face of changing circumstances. Most important, he doesn’t dwell overly on minor local details compared to the prize: understanding what this program does.”

To think about:

  • What are the parallels to “indentation rules” in your making universe?
  • How do you and your team foster and respond to incidental learning?
  • Are there ways for you to better structure your thinking/playing spaces to take advantage of affordances, and so sidestep things that get in the way?
  • How can you introduce more vicarious learning into your creative worlds?