Tonight I’m teaching the BAVC kids about Thinking Big and Thinking Small.  I’ve decided that the ability to “Recipeize” the world around you is getting added to my list of webmaker skills.

This one took a while to get added to the mix because I wasn’t sure if it was essential or not, but after talking with enough smart folks, and actually watching people learn, I’ve decided that a lot of the “how do I?” questions that come up are the result of not understand how to break a problem down into its composite bits.

This may not be webmaker-specific (it’s almost more of a life skill) but I think that it hurts you more in webmaker land than it does in most other places.  Just like how not putting your hand on firey-hot objects is a life skill, but I would still teach it in a cooking class where you’re more likely to need it.

First, we’re going to take an everyday task, like “Make a sandwich“.  The conversation goes like this:

“How do I make a sandwich?”

“You take two pieces of bread and […]”

“Where do I get the bread?”

“Your fridge.”

“How do I get it from the fridge?”

“You open the door and get it.”

“Okay, so I open the door.  Now how do I know where the bread is?”

“You look around and find it.”

“Okay, so I look around and the first object is mustard.”

“Keep looking.”

“Okay, so we have our first two steps now.  First, we open the fridge.  Second, we examine each object.  If it’s the bread, we take it out.  If not, we look at the next object.  And we keep repeating until we find the bread.  What next?”

I’ve done a similar exercise with the CSSI kids (though we used technical examples, like how does work?) and there’s an interesting turning point where they go from thinking I’m just being an annoying hyper-specific troublemaker, to understanding that some of these “simple” steps aren’t really so simple.  That turning point is what I’m looking for.

We then break into groups, and I’ve got a bunch of other every day activities for them to break down, like how do you play blackjack?  Groups are essential here because you really want them to ask each other “but how do you foo?” questions.

So that’s Thinking Small.  Taking a problem and forcing yourself to get into the nitty gritty details of how it breaks down.  What about Thinking Big?

We’re going to start with a giant, impossible-to-measure problem, like “How many chickens does San Francisco eat every year?

“How many chickens does San Francisco eat every year?”

Stunned silence.

“Well, is the answer 1?  1 chicken?”


“Is the answer one hundred thousand million billion?”


“So you have some idea of where it should fall.  Some guesses are better than others.  Let’s see.  How often did you eat chicken last week?”

“3 times?”

“Okay, so if that was an average week, you eat chicken 3 times a week.  Was it a whole chicken?”

“Wait, I’m a vegetarian.”

“Okay, so what percentage of the people in San Francisco do we think are vegetarian?”

“A third?”

“Okay, so what if we say that a third of the people eat chicken never, and the rest eat it about 3 times per week.  Does that sound about right?  How many people live in the city?”


The mental hurdle to get over here is the incorrectly learned assumption that if your answer isn’t perfect, it’s not worth measuring.  I remember asking these vague questions in software engineer interview questions to see if they could deconstruct these types of no-right-answer questions into realistic parts; it would tell you a lot about how candidates think.

Once we get to an answer on the chicken problem (and it doesn’t matter what that answer is), we break into groups again and they set to work on their own big questions, like “How often will you type the letter ‘q’ in your lifetime?”

Anyway, I’m curious to see how this goes over.  The interesting thing is that while these skills may not feel like they have anything to do with learning how to make things on the web, this type of thinking is in fact the first step to tackling a big problem like how to make something new on the web.

Future idea (not enough time this session): it would be cool to hand them a technical challenge before and after the class and see if spending a while thinking about problem deconstruction helps them improve their methodology on the unrelated technical challenge.