As we’re in the process of auditing and redoing our introductory talk-throughs, we find ourselves discussing the different approaches to teaching variables and debating which analogies make variables the most approachable to newbies.
There are a few aspects of variables that we’d ideally like new learners to understand:
- A variable has both a “name” and a “value”.
- A variable can be used multiple times throughout the code.
There are some aspects that maybe they don’t need to understand at first, but it’d be a nice bonus if they did:
- Variables can hold data of different sizes.
- Variables can be different types.
- Multiple variables can point at the same value (more true in the case of objects than primitives).
We’ve considered a few analogies ourselves, and I asked around to find out what other folks use. Here’s a round-up of them, with scribbles approximating how one might visualize them on a whiteboard. It’s not always necessary to be able to visualize an analogy, but it helps.
We currently use this analogy in our first talk-through on variables. We don’t love it, however – we don’t usually think of buckets as having labels in the real world, so this analogy doesn’t help reinforce the important idea of variables being labels for containers that hold values.
We like this analogy because drawers are often labeled as to their contents, and the idea actually maps nicely to what happens behind the scenes in a computer too, with the registers. Kevin Henney points out that the “labeled boxes” analogy also works nicely for introducing “arrays (a row or column of boxes) and objects (a group of boxes).” Ikai Lan likes how “box size is a good analogy for type discussions later on.”
Similar to drawers, envelopes often have something on the outside (a name or address) and a value on the inside (the letter). An envelope can also be different sizes, which lends itself nicely to talking about storing data types. But, the address doesn’t map perfectly to variable names, and I prefer using the envelopes analogy to explain concepts like HTTP requests or message sending systems.
“You should imagine variables as tentacles, rather than boxes. They do not contain values, they grasp them ― two variables can refer to the same value.”
“Name tags” / “Names”
This analogy really emphasizes the named aspect of variables. Want to refer to something by name? Then slap a name tag on it!
“Code like a Pythonista” uses this analogy extensively with diagrams demonstrating what happens when you re-assign a variable and assign two variables to the same value. They specifically stress that in Python, variables “are not labeled boxes.”
“Values in disguise”
Math.com describes algebraic variables with interesting wording:
“In algebraic expressions, letters represent variables. These letters are actually numbers in disguise. In this expression, the variables are x and y. We call these letters “variables” because the numbers they represent can vary—that is, we can substitute one or more numbers for the letters in the expression.”
The notion of disguise is fun and playful, and it’s nice how they’ve attempted to correlate the actual word “variable” to its meaning. We often forget in programming how weird some of our terminology is, and that it might help learners to connect the words to their meaning.
Which should we use?
Of all of those, we will likely be going with “labeled boxes” for future lessons, because it’s a familiar concept and the analogy covers many aspects of variables.
We’ll keep trying out approaches and seeing how students respond. In the meantime, we’d love to hear what your experience with teaching and learning variables. What worked? What made it click? What didn’t work?