Teaching people to think about code instead of acing a test

Thursday, December 19th, 2013 at 9:15 pm

One of my biggest bugbears with education, learning and teaching – especially online – is the focus we have on testing people by giving them multiple choice questions or having them fill out a very specific and rigidly defined test. This is a remnant from school education, where it is important to compare pupils and to also make it easy to measure the success rate and effectiveness of the teacher. Overly simplified, our school systems are designed to create new professors, not people who use the knowledge elsewhere. Ken Robinson covered this nicely in his TED talk How schools kill creativity and Salman Khan (founder of Khan Academy) ran with it in his TED talk as well.

The problem with rigid tests is that they can be gamed. I knew quite a few students and interviewees who learned information by heart, aced tests and came out not remembering a single thing let alone being able to apply the knowledge in a different scenario. The learned the what, but not the why.

Job interviewers make the mistake of having a fixed set of questions and then compare different applicants by how they fared. This is not only boring for the interviewer, it also doesn’t tell you much about how the person you interview ticks. And in the end you want to work with that person, see them grow and apply their problem solving skills in various different scenarios. At Yahoo we had a great way of doing this – we gave people a code exercise that encompassed creating a small web site from a photoshop comp. We told them what the thing should do and then let them decide how to approach it. We looked at the result they sent us and if it worked nicely, we invited them to an interview where the first half hour or hour was them explaining to us why they approached solving the problem in a certain way, what their frustrations were, and how they cut corners and why. We learned a lot about the people that way, because programmers who can explain what they did are people who can code.

This is why I am very happy to see that some people are creative enough to approach teaching to code differently than others. There are quite a few new resources out there that teach coding by describing problems and asking the learner to write code that then gets validated in a worker thread (in the case of JavaScript). Code Combat for example is a beautiful product using that approach.

Yesterday I was super happy to see that Mozillian Brian Bondy who took in onto himself to create a series of videos explaining how to contribute to Firefox at codefirefox.com added a series of small coding exercises to this endeavour.

Instead of telling you to “create variable a and assign the value foo to it as a string” the exercises on codefirefox.com are task descriptions like

Create a new variable declaration and initialize it with a literal value in one statement.

This teaches you the lingo (you might have to look it up to understand the question but you now what a declaration is afterwards) and allows you to choose what you want to do. You creatively code instead of answering a question. There is a text editor embedded in the page that analyses what you do and if you manage to get a task done, ticks it off for you. All you do is code instead of following yet another “next lesson” button navigation.

Even better is that Brian released the framework that allows you to create tests like that. Under the hood it uses Acorn by Marijn Haverbeke in a web worker to analyse the code and test it against assertions you defined in a simple API.