True story: I was once interviewing a candidate for a software engineering job and asked him to write an algorithm to sort a list of words.  “You can’t sort words,” he replied, “you can only sort numbers.”

Fearing that we were delving into some sort of zen riddle about what words are, I clarified: “I just mean, sort the words alphabetically.  Like at a library or in the phone book.”

He shook his head.  “We only learned algorithms for sorting numbers in school.  Not words.”

“Well,” I threw him a bone, “maybe we can come up with a way now to sort words.  What if you had a list of words in front of you, not on the computer, just on post-it notes, and you wanted to sort them in alphabetical order.  What would you do?”

“I can’t,” he replied.  “I haven’t memorized that algorithm.”

Yikes.

Cathy Davidson has been arguing recently that we should teach a 4th ‘R’, algorithms, on par with literacy and math.  To my delight, what she talks about is not just teaching existing algorithms to kids (“first we’re gonna memorize bubble sort, then on to merge sort“), but rather teaching them how to think about the world algorithmically.

The distinction is an important one.  As Cathy says:

Algorithmic thinking is less about “learning code” than “learning to code.”

Cathy’s thoughts on this, as well as talking to folks like Matthew Levine from Google and Mitch Resnick from the MIT Media Lab has convinced me that understanding how to break apart a problem into its composite parts is an essential web literacy skill, which is why it appeared in my recent skill diagram:

I call it “recipe’izing tasks” for two reasons:

    1. My marketing skills suck.
    2. I think that the concept of building a recipe helps to emphasize that this is more about a way of thinking and approaching problems than it is about applying well-researched coding algorithms to tasks.

I tested out teaching this skill last night with the BAVC students where I gave them the job of thinking big and thinking small: how do you deconstruct “make a sandwich?” into its specific parts, and how do you deconstruct “how many chickens does the city of SF eat” into a problem that’s estimateable?

One of the coolest outcomes of doing a few of these activities was that I had them split into pairs (there were 4 groups) and tackle the problem: “How often will you hit the letter ‘q’ in your lifetime?” and all of the groups came up with answers that were the same order of magnitude.  That certainly doesn’t prove anything, but it was impressive to see how quickly they latched onto the idea of breaking down a complex problem into estimateable chunks.

They also tackled problems like how to break “After you hit a ball in baseball, what do you do?” into a set of steps.  Each group discovered their own set of problems (“hmm how do we know if we should run to the next base or not?“) and edge cases (“if we’re tagged out, we have to remember to go back to the dugout“).

We didn’t even discuss code or technical problems, but most programmers would recognize what they were building as a form of pseudocode.

Thinking about the world this way is certainly not specific to web making.  But having this type of problem solving in ones mental toolkit is definitely a huge empowering asset when it comes time to take a vague problem and turn it into a set of interpretable steps.

Most importantly, this skill isn’t about knowing a particular coding language: it’s about understanding how to take something you want to happen and think through all of the processes, decision trees, edge cases and exceptions necessary to make it happen.

If you’re interested to hear more about this, Cathy’s going to be talking with us tomorrow (Feb 1st) about this topic, and how we can turn the vague notion of “teaching algorithms is good” into a part of Mozilla’s 2012 webmaker goals.