The Bridge to Higher Learning: Why Analogies Still Matter in University Classrooms
There were moments in my classes when I could almost see the problem on a student's face....
I had explained the concept. The terminology was technically correct. The diagram was on the screen. The example was working. Yet the student still wasn't quite there.
Sometimes, the answer was not another explanation.
It was an analogy.
Over the years, particularly when teaching university freshmen, I found myself using everyday situations to explain concepts that initially seemed far removed from everyday life.
A new programming paradigm, an algorithm, a technical process full of terminology that students had never encountered before.
And quite often, something very simple worked.
I would take the concept out of the textbook for a moment and put it into a situation they already understood or knew.
Then, once they understood the idea, we could bring it back into the technical context.
I found this particularly useful with students who were moving from what they already knew into something conceptually new.
But there is a bigger reason why I think this is worth talking about.
When the familiar disappears
The use of analogies is hardly new.
In school education, particularly in Science, Technology and other concept-heavy subjects, teachers often use familiar situations to help children understand unfamiliar ideas.
A teacher may explain electricity through the analogy of water flowing through pipes.
The solar system may be represented through a model. The very concept of Systems and Subsystems can be explained through so many examples from the world around us.
A difficult scientific process may be connected to something students have experienced in everyday life.
The teacher doesn't use an analogy to make the subject less rigorous. They use it to give the learner something familiar to hold on to while they approach the new idea in its purely technical or scientific context.
But something changes when students enter higher education.
University is expected to operate at a different level, at a rather elevated intellectual level.
And rightly so.
Students are expected to deal with abstraction, technical terminology, theoretical frameworks, disciplinary knowledge and increasingly independent learning.
A university course cannot remain at the level of simplified everyday explanations.
But there is another truth that is sometimes overlooked.
Higher education may require students to reach a higher level of thinking. That does not mean every student can begin at that level on day one.
Worse still, many of them are still very much in that "learning from my teacher" mode.
Some students make that transition comfortably. Others don't.
And when they struggle, we sometimes assume that the problem is a lack of ability or preparation.
Sometimes it is, but sometimes the student simply hasn't found the bridge.
When the jargon gets in the way
Think about what happens when a beginner encounters a new technical concept.
They are not just learning one thing.
They may be learning new terminology, new symbols, new rules, new relationships between concepts and perhaps even a completely new way of thinking about a problem .... all mixed up in a huge pile of high-level knowledge.
For a freshman learning programming, terms such as object, class, method, inheritance, interface, polymorphism and encapsulation can become a wall of vocabulary.
The problem is not necessarily that the student is incapable of understanding those ideas.
They may simply have nothing familiar to connect those ideas to.
And when everything is unfamiliar, learning can become unnecessarily heavy.
This is where I found analogies useful.
Not as a replacement for the technical explanation but as a bridge to it.
An ATM, a queue and a CPU
Imagine you walk up to an ATM and there are five people ahead of you.
You join the queue.
The first person starts using the machine.
You wait.
After a while you get a little impatient. The line is not moving. Someone is doing multiple transactions on the ATM, perhaps.
You have no idea how many transactions that person is going to make. You have no idea how many transactions each of those four persons before you is going to make either.
Perhaps they are simply withdrawing some cash through multiple transactions. Perhaps they are checking their balance, transferring money, paying a bill and doing several other things.
You are still waiting.
Now think of the way it usually works at an ATM. Each person is allowed to continue using the ATM until they have finished their job on that machine.
That gives us a very simple way of thinking about First-Come, First-Served (FCFS) scheduling.
The person who arrived first gets served first.
Simple.
But there is a problem.
What if the person at the front takes a very long time?
Everyone behind them has to wait.
In computing, a long-running process can similarly delay processes waiting behind it.
Now we can take the analogy one step further.
What if we change the rule?
Imagine there is a security guard at the ATM.
The guard implements a rule:
“You can make up to four transactions max in one go. After that, you must step away and allow the next person to use the machine.”
So the person makes four transactions.
Then they leave the ATM and go to the back of the queue.
The next person gets his/her turn for his 4 transaction (in CPU terms, time quantum or slice of time).
After everyone else has had an opportunity, the first person comes around again and gets another four transactions.
And the cycle continues.
Now the basic idea behind Round Robin (RR) becomes much easier to visualise.
The ATM is the CPU.
The people waiting are processes.
The limited number of transactions represents the fixed time quantum, the amount of CPU time allocated to a process before the scheduler picks another process from the ready queue.
The queue determines who gets the next turn.
Returning to the back of the queue explains the repeated allocation of CPU time.
The students haven't learned the algorithm yet.
But they now have somewhere to start.
From C to Object-Oriented Programming
I had to use a similar approach when students moved from procedural programming in C to Object-Oriented Programming.
For many freshmen, this transition was surprisingly difficult, conceptually.
They had already learned to think in terms of functions.
Give the program a function. Call the function. Get the result.
Then suddenly they were being asked to think about objects, classes, attributes, methods and behaviour.
So sometimes I would make myself the program. 😀
Imagine that I am a program written in C. Someone who wrote me gave me a few functions.
One of them is:
pick up ()
Another is:
put down ()
If someone says:
“Teacher, pick up ()!”
I am supposed to respond by picking something up.
If they say:
“Teacher, put down ()!”
I am supposed to put something down.
Everything seems fine.
Until someone says:
“Teacher, pick up ()!”
And I don't move.
Why?
Because they didn't tell me what to pick up.
The question becomes: Pick up what?
That gave us a simple way into thinking about actions in relation to the things that perform them and the data or state involved as parameters.
Then I would take the analogy one step further.
The monkey and the deer
Imagine there is a monkey and a deer.
You say:
“Monkey, climb tree.”
The monkey climbs the tree.
Now you say:
“Deer, climb tree.”
The deer doesn't move.
Why?
Because whoever created and defined the Deer class didn't give it a climb() method.
So all the monkey objects have that behaviour, but the deer objects don't.
Again, the analogy itself isn't Object-Oriented Programming. But it gives a beginner something concrete to think about the structure and behaviour of Class and Objects.
An Object can have particular behaviours, as long as those behaviours are defined inside its Class.
Different objects originating from different classes can have different sets of behaviours.
And simply telling an object to perform an action doesn't mean that the object necessarily knows how to perform it. It all depends on how the class it represents was defined .
From there, we can move into the actual concepts of classes, objects and methods.
The analogy has done its job.
Sometimes the analogy helps us structure our thinking
There was another situation where I found analogies particularly useful.
Sometimes the problem was not that students couldn't understand a technical definition.
The problem was that they didn't know where to start thinking.
Database design was a good example.
When students were first introduced to databases, I would sometimes ask them to forget about databases for a moment.
Imagine you have been asked to set up a fully functional library. Where would you begin?
You wouldn't start by throwing 5,000 books into an empty plot of land and call it a library, would you?
First, you need to construct the building. That becomes our database.
Then you need to decide how the space will be organised.
Those become our tables, that will hold all your precious books (data) in an orderly manner.
Then you have another problem. Suppose the library now contains 5,000 books.
How would someone find one particular book?
You wouldn't expect the librarian to walk through every shelf and look at every book.
You would need some kind of catalogue.
The catalogue contains information about the books: their titles, authors, subjects, locations and other identifying information.
Now imagine that I walk into the library and say:
“I need this particular book.”
I don't need to know which cabinet or shelf contains it. I don't need to walk through the entire collection.
I make my request at the front desk.
The library's management system takes my request, looks at the catalogue, identifies where the relevant book is stored, and retrieves it.
Now we have a much more concrete way of thinking about the different components of a database system.
The library building gives us the idea of the database itself.
The cabinets and shelves give us a way to think about tables and organised storage.
The books represent the actual data.
The catalogue helps us think about metadata - information about the data that helps us identify, locate and manage it.
And the library front desk or management system gives us an intuitive starting point for understanding the role of an MS in DB design.
The important thing is that the analogy also gives students a sequence for thinking:
Where will I keep the data?
↓
How will I organise it?
↓
How will I describe and locate it?
↓
How will someone request it?
↓
How will the system retrieve it?
That is more than remembering definitions. It is structured thinking.
The student is beginning to see that designing a database is not simply about creating tables and writing SQL queries.
There is a system to think about.
And once that mental structure is in place, the technical concepts have somewhere to fit.
Of course, the analogy has limits. A real database doesn't have shelves, and a DBMS doesn't literally walk to a cabinet and bring back a book.
But that isn't the point.
The analogy gives the beginner a conceptual map.
Once they have the map, we can gradually replace the familiar terms with the technical ones and explore what actually happens inside the system.
That, for me, is one of the most useful things an analogy can do.
It doesn't just answer:
“What does this technical term mean?”
Sometimes it helps answer a more important question:
“How should I think about this system?”
Sometimes we use analogies without even realising it
There is a slightly funny story behind my database example.
When I first learned Microsoft Access many years ago, nobody taught me the logic of it.
I more or less reasoned my way through it.
At the time, I noticed that many people around me preferred Excel. Access, on the other hand, seemed to annoy people.
Why?
Because in Access, you often have to think before you click.
Make a change without understanding what you are changing, and suddenly you can be confronted with a rather intimidating warning message containing several lines of text that seem to be asking you to reconsider your entire life. 😀
I eventually realised that there was actually a very simple logic behind many of those warnings.
I went back to my library.
Imagine that you have a cabinet containing hundreds of carefully organised books, valuable books.
The cabinet has already been designed and the books are already inside it.
Now you decide:
“I think I'll change the structure of this cabinet.”
Perhaps you want to remove one of the sections. Perhaps you want to change the size of a compartment. Perhaps you want to move things around.
Wouldn't you expect someone to stop you and say:
“Wait a minute. There are valuable books inside this cabinet. Are you sure you want to do that?”
That was how I began to think about Access.
The table structure was the cabinet. The data stored in records were the books.
Changing the structure of an empty cabinet is one thing. Changing its structure after it has been filled with carefully organised valuable books is another.
Suddenly, those intimidating warning messages made much more sense.
I wasn't simply being asked to click Yes or No.
The system was essentially telling me:
“Think carefully. You are about to change the structure that your existing data depends on.”
And that was one of the reasons I actually came to appreciate Access in those good old days.
It forced me to think about the structure of the data before I started manipulating it.
Excel often lets us begin working immediately.
Access frequently asks us to think first.
That can make Access feel frustrating when we are beginners.
But it can also teach us something important about database design:
The structure matters.
And that lesson stayed with me.
Looking back, I realise that I wasn't consciously following some formal teaching strategy when I first learned Access.
I was simply trying to make sense of an unfamiliar system by connecting it to something I already understood.
In other words, I was using an analogy before I even knew I was using one.
Mom's favourite dish
This was another analogy I used quite often with my freshmen when introducing computational thinking and problem-solving.
Imagine you ask your Mom:
“Can you cook my favourite dish for dinner tonight? You know, the one I really love.”
Mom says:
“Alright. I can make it. But I need potatoes, carrots, meat, vegetables, these particular spices, and a few other things. Go to the market and get them.”
So you rush to the market.
You buy everything on the list and bring them home. You hand the ingredients to Mom.
She disappears into the kitchen for the next hour.
And then, at dinner time, there it is. Your favourite dish — hot, fresh and ready to eat.
Then I would ask my students a deceptively simple question:
“Which came first - the input, the process or the output?”
And this was where the fun usually began.
Students would make all sorts of initial arguments.
Some would say input.
Others would say process.
And some would immediately say output.
We would debate it for a while.
Eventually, we would go back to the beginning.
What did you want in the first place?
The dish.
The desired output was already in your mom's mind before she started thinking about the ingredients (inputs).
Once that output was clear, you could work backwards.
What inputs do I need?
potatoes , carrots, meat, vegetables, spices, and whatever else the recipe requires.
Once you source those ingredients from market, only then can Mom carry out the process - the recipe or algorithm that transforms those inputs into the desired result.
And then comes the final output, the deliverable, the solution.
So we could represent the thinking very simply:
Desired Output → Required Inputs → Process / Algorithm → Final Output
Of course, real computational problems are much more complex than cooking dinner.
But the thinking pattern is useful.
Before asking:
“How do I do this?”
It always helps to ask:
“What am I trying to produce?”
Once the desired output is clear, we can start thinking about the inputs required and the process or algorithm that can transform those inputs into the result we want.
And, if certain required inputs are not available, we may need to change the algorithm a bit to get to the desired goal.
My students liked it. They were sometimes wrong at first - and that was perfectly fine.
The discussion was the point because that helped the flow of logic to sink in.
We were not trying to make them memorise a definition of computational thinking.
We were trying to get them to think about how they think.
And that, perhaps, is where an everyday analogy becomes more than just an explanation.
The important part: the analogy is not the lesson
This is where I think we need to be careful.
- An analogy is not the concept itself.
- And every analogy eventually breaks down.
- An ATM security guard isn't really a CPU scheduler.
- A monkey isn't a software object.
- A deer doesn't actually belong to a programming class.
If we take an analogy too literally, it can create new misconceptions instead of removing them.
So I see analogies as temporary scaffolding.
They help us get started. They help establish an intuitive understanding. But then we have to move back to the real thing.
The students eventually need to understand the actual algorithm, the actual code, the actual architecture and the actual terminology.
The analogy should eventually become unnecessary.
That, to me, is an important test.
If the analogy helps students understand the concept but they can later work without the analogy, it has probably served its purpose.
Higher education does not have to mean higher barriers
There is sometimes an assumption that because university education is supposed to be more advanced, the teaching itself should immediately become more abstract and technical.
There is some truth in that. Students do need to move beyond simplified explanations.
- They need to develop disciplinary thinking.
- They need to become comfortable with technical language.
- They need to learn to work independently.
But rigour and accessibility are not opposites.
We can challenge students intellectually while still giving them a way into the subject.
In fact, perhaps the greater challenge is not making the content simpler.
It is finding a way to make the first encounter with the content less intimidating.
Once students understand the underlying idea, we can increase the level of abstraction.
- We can introduce the terminology.
- We can remove the analogy.
- We can ask harder questions.
- We can ask them to apply the concept in unfamiliar situations.
- We can eventually expect them to explain the idea without any scaffold at all.
The analogy is simply the first step.
What happens when students never find the bridge?
This matters because the transition into university is not equally easy for everyone.
A student can encounter one difficult concept, then another, then another. The gaps begin to accumulate.
They begin memorising rather than understanding. Perhaps they pass one examination. But the next course builds on the concepts they never fully understood.
Over time, this can affect confidence, engagement and persistence. Eventually, the problem may look like:
“This student isn't interested.”
when the underlying issue may be:
“This student never found a way into the subject.”
Of course, analogies alone can not solve the complex reasons why students disengage or leave university.
But they can help remove one unnecessary barrier: the feeling that a difficult technical concept is completely disconnected from anything the learner already understands.
Not every concept needs an analogy
I would not suggest that teachers turn every technical concept into an everyday story.
That can become distracting. Some concepts are better explained directly.
- Some need diagrams.
- Some need demonstrations.
- Some need code.
- Some need students to experiment and discover what happens.
And sometimes an analogy can actually make a simple concept more complicated too.
The trick is knowing when the learner needs a bridge.
For me, that usually happened when I noticed that students were getting stuck not because they lacked effort, but because the conceptual jump was too large.
That was often my signal to step away from the textbook for a moment.
Connect, translate, then let go
Looking back, I think I usually followed three steps, even though I never consciously planned them that way:
- Connect - Start with something the learner already understands.
- Translate - Map the familiar situation onto the unfamiliar technical concept.
- Let go - Gradually remove the analogy and work with the real technical model.
That last step is important.
The goal is not to make students permanently dependent on simplified explanations.
The goal is to help them cross the gap. Once they are across, they should be able to work with the technical concept itself.
Perhaps an analogy is simply a doorway
One of the things I enjoyed most about teaching was that the explanation that worked yesterday was not always the explanation that would work today with every other student.
Sometimes I would explain something in three different ways and could still see confusion.
Then an everyday example would suddenly make sense.
And sometimes the analogy would come to me almost spontaneously, almost in desperation, because I could feel where the student was getting stuck.
That is probably one of the reasons I have always enjoyed teaching.
It is not simply about knowing the subject and dispensing knowledge at an elevated level. You have to find a way into the subject.
For a beginner, the doorway is often not the terminology.
It may be something they already know.
- A queue (FCFS)
- An ATM (CPU)
- Classroom doors and windows (System interface)
- Mom's delicious dish preparation (Computational Thinking: output >> input >> process (algorithm))
- Traffic congestion (Deadlock)
- A restaurant (multi-tiered service)
- A hotel check-in check-out scenario (Mutex and Semaphores)
- A hotel room booking and check-in on arrival scenario (Resource Allocation and Acquisition)
- Harry Potter series of books, volume# > page# > line# (Multi-level Paging in memory management)
..... many many more!
Higher education should challenge students. It should take them towards abstraction, disciplinary depth and independent thinking.
But getting students to that level does not necessarily mean starting them there.
An analogy is not a lowering of the academic level. Sometimes it is simply the staircase that helps a learner reach it.
And perhaps that is what a good analogy does.
It doesn't make a difficult subject simple.
It gives the learner a place to begin.
What do you think?
Have you used analogies in your own teaching, particularly when introducing difficult or highly technical concepts?
I'd love to hear from teachers, lecturers, academic leaders and other education professionals about the analogies that have worked for them - or perhaps those that didn't work as expected.
Do you think analogies have a place in higher education, or should students be encouraged to move more quickly into the formal language and abstraction of their discipline?
Different perspectives and thoughtful disagreement are welcome. The aim is to learn from one another and keep the conversation going.
Comments
Post a Comment