Christian Heilmann

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.

calvin finds a loophole in a test

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.

var c = new Codec();
c.addAssertion("x = 3;");
c.addAssertion("x++", { blacklist: true, otherProps: "hi" });
c.parseSample("if (x) { x = 3; }", function(err) {
  console.log('whitelist hit? ' + c.assertions[0].hit);
  console.log('blacklist hit? ' + c.assertions[1].hit);
});

The codefirefox exercise module code is available on GitHub.

I am very excited about this and hope that some people will take this on. Brian is doing a great job with this and more is to come.

Share on Mastodon (needs instance)

Share on Twitter

Newsletter

Check out the Dev Digest Newsletter I write every week for WeAreDevelopers. Latest issues:

Dev Digest 146: 🥱 React fatigue 📊 Query anything with SQL 🧠 AI News

Why it may not be needed to learn React, why Deepfake masks will be a big problem and your spirit animal in body fat! 

Dev Digest 147: Free Copilot! Panel: AI and devs! RTO is bad! Pi plays!

Free Copilot! Experts discuss what AI means for devs. Don't trust containers. Mandated RTO means brain drain. And Pi plays Pokemon!

Dev Digest 148: Behind the scenes of Dev Digest & end of the year reports.

In 50 editions of Dev Digest we gave you 2081 resources. Join us in looking back and learn about all the trends this year.

Dev Digest 149: Wordpress break, VW tracking leak, ChatGPT vs Google.

Slowly starting 2025 we look at ChatGPT vs Google, Copilot vs. Cursor and the state of AI crawlers to replace web search…

Dev Digest 150: Shifting manually to AI.

Manual coding is becoming less of a skill. How can we ensure the quality of generated code? Also, unpacking an APK can get you an AI model.

My other work: