Pick the Right Tool For the Job

Avoid the vicious cycle of "I only use A because I don't like B because I can't remember how to use B because I only use A."

Want to get notified about new posts? Join the mailing list and follow on X/Twitter.

One of the key things that we’re going to do in our Intro Programming I course is force students to master all sorts of coding techniques. When you pick a tool out of your toolbox, you need to be picking that tool because it’s the right tool for the job, not because it’s the tool you’re most familiar with.

Time for a little story. Back when I was teaching this stuff manually to kids in our original school program, they would often try to use arrays for everything.

For instance, instead of storing word counts in a dictionary where keys are words and values are counts, they might use two arrays, one storing words and the other storing counts.

And then they’d have crap like

>>> counts_array[words_array.index(word)]

peppered throughout in their code, instead of just

>>> count_by_word[word]

which is not only cleaner but also more efficient.

Despite my repeatedly pointing this out to them, they would continue doing this same damn array crap every time simply because they weren’t as comfortable with dictionary syntax.

Why weren’t they comfortable with dictionary syntax? Well, we had covered it in the past, they did some practice problems on it, but they had gotten rusty, and now they were avoiding it, which was leading them to get even rustier.

You see how this quickly spirals into a vicious cycle: “I only use arrays because I don’t like dictionaries because I can’t remember how to use them because I only use arrays”

Initially I thought they’d naturally grow out of the array manipulation crap as the problems got more and more complicated and it became more and more inconvenient to avoid using dictionaries. But I underestimated the degree to which people (especially kids) can be locally clever yet globally unreasonable.

As time went on I observed the kids getting better and better at using arrays in convoluted ways… like, developing automaticity on an anti-pattern. And then they’d get stuck on problems because they were taking so long to debug their Rube-Goldberg array manipulator.

So I had to go kind of hardline and refuse to accept code until it was clean. Getting the code producing the correct result was just the entry-level requirement for me to consider awarding credit. It had to be reasonably clean – or, at least, not convoluted.

That worked for my in-person classes. But how do we prevent the same issue from happening to students on the automated system? We can’t be manually looking at code!

This is an instance where an ounce of prevention is worth a pound of cure. When you let a problem like this spiral out of control, the solution becomes way more complicated, sometimes even intractable. But when you trace it back to the root cause, a simple patch can avoid the problem in its entirety.

In the case of this “I only use arrays because I don’t like dictionaries because I can’t remember how to use them because I only use arrays” story, the issue is that students weren’t getting enough practice working with dictionaries.

It’s like someone signs up for martial arts classes and they only want to punch. They learned how to kick in one class a while ago, but they’re more comfortable punching so that’s the one move that they use in all their matches. And they’ve gotten good enough at their punching game that it works out okay for them as long as their opponent isn’t too good.

What do you do? Well, obviously, you need to force them to practice their kicks! Not just in that one class but also into the future in progressively more complicated contexts. You don’t just teach them how to kick once and then leave it to them whether or not they try to use kicks in their matches. You have them train in some matches where only kicks are allowed.

Sure, still give them matches where anything goes, but also make them participate in matches where only a particular technique is allowed. That way, every action they take during their “anything goes” matches, they’re making an informed decision to take the action because it’s the most appropriate action for the situation, not because it’s the only action they’re comfortable with.

And that’s what we’re going to do in our Intro Programming I course. We’re going to make you learn how to work with dictionaries and we’re going to have problems where you’re given a rigid code template that you have to fill out using the dictionary approach.

We’re also going to have free-response coding problems where no template is provided and you have to write everything from scratch. And when you do those, you’re going to be so strong on all your sub-skills so that you naturally gravitate towards whatever is the right tool for the job.

And we’re going to do this for all sorts of coding techniques. Dictionary usage, recursion, helper functions, you name it. We’re going to force you to master all of these.

TLDR: I don’t care if you don’t like coding techniques X, Y, or Z – you’re still going to get really good at them, and when you have the freedom to choose your approach, you might find yourself gravitating towards them if they’re the right tool for the job. You might even start to like them.

Want to get notified about new posts? Join the mailing list and follow on X/Twitter.