Analogy is a powerful teaching tool. A good analogy helps learners create and organize mental structure. It makes learning personal and relevant, because it connects a new concept to a learner’s experience. A good analogy provides mental scaffolding.
It’s all analogy, so a good analogy is better than a bad one.
Boiling it down to programming terms, we could define a function as a “named block of expressions and statements which is executed by listing the function’s name and providing arguments”. Again, that’s not necessarily wrong, but we haven’t successfully escaped analogy. For new programmers, blocks, expressions, and arguments are still fuzzy concepts. From their perspective, we’re building an analogy on top of concepts that are themselves half-formed analogies.
Written lessons and first discussions should lead with an analogy that resonates with everyone in the course. It should sacrifice detail in hopes of a first intuition.
A function with parameters is like cooking dinner. The high-level steps are the same: prep, cook, serve, and tidy. But depending on the recipe, you end up with a different meal.
As you get to know your students, try analogies that are most relevant to small groups and individuals. The more personal an analogy, the better. A personal analogy creates connection and meaning.
If there are musicians in your course, a function is like a song’s refrain. It’s the same set of musical instructions, which can be repeated at will. A refrain might accept a key signature argument since refrains are sometimes repeated in a different key.
A cook might understand functions as sub-recipes. If the recipe on page 32 calls for 2 cups of bechamel, the bechamel recipe on page 112 is a function that can be executed when it’s needed. It can be executed from different recipes, which can be viewed as functions themselves.
Knitting is just programming in fiber, so there’s bound to be a good function analogy for knitters. Do you know one?
Recognize the limits.
An analogy can never be the thing itself. If, after several rounds of analogy, the learner’s procedural mastery isn’t improving, try something else. Even if their mastery is improving, always teach from several angles.
Provide many and varied examples. Ask students to make small changes. Share code that’s broken in an obvious way and ask them to fix it. Sometimes, all it takes is persistence and a debugger to grasp how functions are defined and data flows into and out of function calls.
Watch out for damaging analogy. Rarely, an analogy can confuse a learner and leave them in a worse place than where they started. Read the room. If there’s confusion without progress or worse, a reversal of progress, disengage. Take a break. Try something else.
Encourage analogy-making and trust the learner.
The best analogies are the most relevant and personal. Encourage students to make their own. If you understand the topic, check that the analogy is consistent and sensible. If it’s not, nudge them in the right direction. Ask them to refine.
If you don’t understand the topic, trust the learner. Encourage all students to explain their thinking to classmates and instructors. Then insist on civil feedback.
Finally, if the student is making steady progress on their procedural mastery and their analogies don’t make sense, don’t sweat it. Mastery is an incredibly quirky and personal thing. My subjective experience of defining and executing functions is likely very different than yours, even though the result is the same. If the student can do the work, a perfect analogy isn’t required.