Learning with Analogies and Metaphors

Science teachers and textbook writers differ widely in their enthusiasm for analogical explanation: some use many analogies while others are wary because they cannot predict how their students or readers will interpret the analogies they use to teach science.

I believe that analogies and metaphors are great for modeling or internalizing an abstract concept in a constructive way. By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic.

A software metaphor is more like a searchlight than a road map. It doesn’t tell you where to find the answer; it tells you how to look for it. A metaphor serves more as a heuristic than it does as a deterministic algorithm. To further elaborate, a heuristic is a technique that helps you look for an answer. Its results are subject to chance because a heuristic tells you only how to look, not what to find.

With that said, you should take these metaphors and analogies with a grain of salt. Use them to give you insight into your programming problems and processes.

Here are some of my favorite metaphors and analogies:

Developing a program is like writing a casual letter- you sit down with pen, ink, and paper and write it from start to finish.”

“Envision creating software as something like planting seeds and growing crops.”

“It’s like the way an oyster makes a pearl, by gradually adding small amounts of calcium carbonate over time. It means that you have to learn how to add to your software systems a small amount at a time.”

“Treating software construction as similar to building construction suggests that careful preparation is needed and illuminates the difference between large and small projects.”

“Thinking of software-development practices as tools in an intellectual toolbox suggests further that every programmer has many tools and that no single tool is right for every job. Choosing the right tool for each problem is one key to being an effective programmer.”

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.