Earlier this year I gave a presentation to a bunch of 10-year-old girl scouts about what it’s like to be an engineer.  Two months later, I gave a presentation to a bunch of college students about what it’s like to be an engineer.

The purpose of both presentations was the same: trying to encourage people (in both these cases, they were underrepresented groups in engineering) that being a software engineer is a fun career that they would enjoy.  I wanted to give them a sense of what sort of problems they would be working to fix in an engineering career, and explain a little bit about what sort of skills make a good engineer.

One of these skills is the ability to think outside the box, and devise concrete solutions to open-ended problems.  To both groups, I wanted them to engage in a little activity to demonstrate the type of thinking that I meant.

The problem that I gave to the girl scouts was: design a bicycle that could seat 10 people.  Then we talked about issues with some designs: how will that very tall bike get under bridges?  What if only one person is pedaling but they have the weight of 10 people to push?  Soon they were anticipating their own problems with various designs and started drawing up all sorts of crazy and awesome sketches.


The problem that I gave to the college students was: design a test that can tell you which videogame is better.  There are some cases where it’s obvious: a game that’s way way too easy is no fun, and a game that’s broken is clearly worse than almost every other game.  But what about two of last year’s best selling games?  If you use sales as a measure, what if one company just did way more advertising than the other?  How do you define “better”?  And whose definition of “better” matters?  They came up with all sorts of user testing scenarios, and even some automated testing ideas.

Each of these problems were tailored to the specific audience (as was the rest of the presentation) but the core ideas were the same.  If someone asked me to, I could probably generate a similar presentation to give to adults considering a second career, or even younger kids, or magic time machine people from the past, or pretty much any audience.

These are instances (instantiations, if you like) of a template: give them an open-ended problem with no right answer, explain some of the constraints, and then let them design it out in small groups.

Some templates would have been absolute failures.  For example: hold a everyone-wide debate about why one piece of technology is better than another.  I suspect this would have resulted in a few strong-minded people yelling, and everyone else’s eyes glazing over.

When it comes to web literacy, I’m hoping that the core curriculum we design is a template for educators to instantiate.  Those who are teaching technology to veteran journalists are going to come at this from a very different angle than those who are teaching web literacy to kids.

But we can’t know what a successful template is without testing a few instantiations.  We fortunately already have a few sandboxes in which to try these ideas, and that’s where I’m hoping we’ll get a nice learning cycle happening for us.

The template generates instances.  We test the instances, and use the feedback to inform and change the template, until we get a template that we feel comfortable with letting lose into the wild, generating whatever instances it may.

The advantage to this approach, rather than building out a rigorous set of course materials, is that it allows educators to customize to their hearts content, and thus will hopefully allow us to not only reach a wider audience, but also reach a wider audience.