Sep 6, 2015
Teaching taste

You can know the name of a bird in all the languages of the world, but when you're finished, you'll know absolutely nothing whatever about the bird."Richard Feynman

I've been teaching programming using my new UI for just about six weeks now, and it's been miraculous and endlessly fascinating to watch a young mind up close. I'm still processing many of my observations and lessons, but I want to describe how one of my students learned something I never meant to teach: consistent indentation.

The only thing I did to help him learn indentation was this: I never ever brought it up. Mostly because I just don't consider it very important, especially at such an early stage. When I wrote programs to demonstrate features I indented as I normally would, then I'd hand over the keyboard, and ignore the fact that my student was abutting each line of code with the left margin.

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.

Once I happened upon this happy result — learning useful skills without harmful metaheuristics — I noticed that the same arc has been playing out in parallel along several other frontlines. My student used to use single-letter variable names, and now he's starting to use words in some situations. He's starting to add comments. He went from having no comments, to commenting every line (including, yes, “increment x”), to noticing that that wasn't useful. Ok, he might take a few decades to figure out that one. I'm looking forward to seeing the same dynamic evolve in where he draws his function boundaries.

To teach taste, stop teaching rules that must be blindly followed. Your rules are at best a threadbare and bastardized distillation of your life experiences, and at worst polluted with old wive's tales and cargo culting. They're often of no help to others in the situations they encounter in their lives, situations that you've likely never experienced before. Just work with others, focus on your shared goal, use all your skills normally and make them available to emulate. Wait for others to notice problems and realize the wisdom of your ways. They'll be more receptive that way, and they'll practice making up their own minds. And, who knows, you may notice that this rule you hew to so closely doesn't actually matter.

mission
Making the big picture easy to see, in software and in society at large.
accomplishments
Code (contributions)
Prose (shorter; favorites)
favorite insights
Programming
Social Dynamics
Life
Making
Work
Cognition
Economics
History
Startups
Social Software