Why information sometimes is very hard to digest and save
As long as I can remember, I’ve had this weird issue with learning new things. Take high school, for example. Subjects like history and geography were a breeze. Even the statistics and probability part of math came naturally to me — but algebra and calculus? That was a whole different story.
It always felt like I was performing a trick rather than actually understanding what I was doing. As if I was mimicking something without knowing the logic behind it. This blog post is a window into how my brain works — how it stores information, how it rejects certain inputs, and why I personally think our education system needs a serious upgrade.
So buckle up.
Here are a few examples of why school often felt like trying to push a square peg through a round hole — with me being the square peg.
Note: when I say “high school,” I’m referring to the Dutch version of pre-university education (called ‘Atheneum’).
Algebra
I chose that class because it was supposed to give me a head start for my studies at a University of Applied Sciences. My plan? Dive into Information Science. (Hey, I’m a geek — remember?)
And there they were: differentiating formulae and integrating them. We had a short introduction to differentiation the year before, where I somehow managed to store the shortcut: -b ± √(b² − 4ac), all divided by 2a.
No clue why it worked — but I remembered the pattern. The teacher showed us the shortcut, told us it could help find the two intersection points of a quadratic equation like ax² + bx + c.
My brain immediately went: Cool trick, but… why?
And with algebra the year after, the whole thing went into overdrive. Suddenly we were differentiating sine, cosine, and increasingly complex tangent functions. And worse — we had to integrate them too. At one point, I finally asked the question that had been haunting me the entire time: “Where would I ever use this in real life? What’s the actual purpose?”
The answer? “Because.”
Yes. That was it. Just… “because.”
And I still remember that moment vividly. Where I was sitting in the classroom. Which desk. Even the time I asked it — a Wednesday afternoon, sometime between 2 and 4 PM. That’s how deeply that non-answer burned itself into my brain. And honestly? That was just the tip of the iceberg when it comes to how my internal archive operates. (Thanks, Archie.)
I failed all the exams. Miserably. Well… except one.
3D geometry.
Spatial reasoning. Shapes. Structures. Something I could visualize. That one actually made sense to me. It wasn’t just symbols — it was something I could mentally walk around in.
Calculating the intersection between two objects? Not a problem.
Figuring out whether two planes would ever collide? Still not a problem.
Even matrix multiplications related to that? Totally fine.
Why?
Because it had context. It had structure. It clicked.
When 3D geometry was explained, I could see it — literally forming in my brain. It had meaning. It made sense. Somehow, it just clicked. And even before calculating whether two planes would collide, I’d already know the answer — instinctively.
Like my brain had run the simulation before the numbers even showed up.
Just before the final exams, I decided to drop Algebra.
Later, when I was in university, all the math came back — same topics, different setting. This time, I passed all the exams. But still, to this day, I regret that neither of my teachers back then could explain why any of it mattered. Why we needed to learn it. Where it could actually be applied in real life.
It always felt like I was solving puzzles with no purpose. And for a brain like mine, that lack of purpose is a dealbreaker.
Physics
For the same reason I took Algebra, I also chose Physics. And at one point, we reached the chapter about heat — and how it transfers between objects. The formula they gave us was: Q = m × c × ΔT
(Energy = mass × specific heat × temperature difference)
Then the teacher gave us a problem to solve. I don’t remember the exact numbers, but it went something like this:
You have a container with 200 liters of water at 20°C.
You also have a solid copper cube weighing 40 kilograms at 80°C.
You drop the copper cube into the water. What will the final temperature be?
My brain immediately asked a very simple question: “Why on earth would I ever drop a cube of copper into a tank of water?”
That’s where it stopped. No context. No meaning. Just numbers, and a scenario that felt completely disconnected from real life.
I eventually taught myself the trick for solving problems like this. I knew how to plug in the numbers and get the result. But I never understood why it worked — or where it would ever apply in real life.
That is… until we had a solar water heater installed at home.
Suddenly, Q = m × c × ΔT wasn’t just a dead formula anymore. It was real. It explained how much energy we needed to heat our shower water. It had purpose. It finally meant something.
For the first time, it actually made sense. I could literally see the water. I could picture its heat content. I could calculate what would happen if I mixed it through a mixing valve — to lower the temperature. I could figure out how much usable hot water we’d end up with.
So a previously meaningless memo — Q = m × c × ΔT — finally got internalized into my system. It had context. It had purpose. It had earned its place in the archive.
And there are more examples. Take springs, for instance.
Picture a spring with a weight attached to it. Now pull the weight down by 20 cm and… calculate whatever. Why on earth would I ever do that? What kind of mad scientist just pulls springs for no reason? And again — sine, cosine, tangent functions everywhere. Oscillation this, frequency that. But WHY?!
Once more, no explanation. No context. Just math for math’s sake.
Learning how to code
When I started my Information Science studies, we began programming in Modula-2. One of the very first courses introduced us to a concept called pointers.
Once again: we learned how pointers worked — not why they mattered. We worked with simple lists, linked by pointers, but without context. Not a single shred of information about where they could actually be used. Just another set of abstract tools.
No purpose. No story. No system to plug it into.
I flunked that first exam. Miserably.
The next semester, we were introduced to a new concept: arrays. And once again — just the bare-bones explanation. No context. No clue where or why you’d use them. I still remember one of the examples:
We had an array with 10 numbers, and we had to multiply each item by 10.
That was it. WHY?!
What was the point? Why are we even doing this? No use case, no real-world example — just math dressed up as code.
I flunked that exam too. And I started to doubt myself.
The weird part? I was already coding at home. I had built software in Turbo Pascal that was actually used in real-world situations. I had created BBS doorway utilities for my own board — small projects, big projects, from a few hundred to a few thousand lines of code.
So why was my experience at university so different from what I was doing at home? Why did it feel so disconnected? Why did that world make sense — and this one didn’t?
Then the third semester started. We got a course called Complex Data Structures.
I still remember the very first day of that class.
“Alright everyone,” the teacher said,
“We’re going to build a library application. You’ll store properties for every book, and we’ll be using pointers and arrays to make it all work.”
He showed us the basic structure of the application. And I swear — I got goosebumps. Literally.
Everything clicked into place.
This was it.
This was the missing link.
I aced that exam.
Not only that — I re-took the earlier exams on pointers and arrays…
And I aced those too.
This was my missing link.
The why.
The where.
What made the difference?
Context.
And a way to create a mental picture inside my brain.
That’s also why I never had any trouble with complex data modeling using Entity/Relationship diagrams. I could see it. Visualize how everything connected. I didn’t care about what normal form the data was in — I just built a working mental model.
And that was enough.
Later, when I started learning Java, the same problem showed up again.
The course began with the classic example: create a “bike” object. Now, I could visualize the bike object just fine. I could picture the bike. I could even imagine the methods attached to it — like brake(), accelerate(), maybe even ringBell().
But the question that instantly popped up in my head was: Why on earth would I ever want to create a “bike” object?
And of course, the course continued — next up: create a subclass called RaceBike.
I understood the concept just fine. Inheritance, specialization, method overriding — no problem at all. But again…
Why?
Why create a RaceBike subclass without any context? No story, no purpose, no system around it — just a floating example in a vacuum.
And once again, the course instructor couldn’t provide any real-world example of where or why you’d use it.
Just more abstract theory, disconnected from reality.
Later, I worked on a project that required Java.
We had to create web services that fetched data from a database and exposed it as a SOAP service — complete with a WSDL definition.
And when I started coding… it clicked.
Instantly.
Same goosebumps as before. Because finally — it had a purpose. The concepts weren’t floating anymore. They were part of something real.
Me, as a trainer
One of the first training courses I ever gave was a three-day introduction to XML.
And one of the very first things I did? I asked each participant what they expected from the course — and whether they were actually planning to use XML any time soon. Throughout the training, I made sure to give concrete, real-world examples of where and how XML could be applied.
And instead of using some random, nonsensical example like describing a bike in XML (yes, again with the bike…), I used the analogy of a speed camera.
In the Netherlands, we had over 1,500 speedcams at the time — so the concept clicked immediately. Everyone could see it. Everyone could imagine the structure, the purpose, the data model. That’s when learning starts to stick.
Even the more complex topics — like XSLT transformations and namespaces (arguably one of the most confusing parts of the XML standard) — were surprisingly easy to explain.
Why?
Because I didn’t show a silly XSL file that transformed nothing into nothing.
Instead, I used a concrete example:
“You have an XML format, taken from a database, with speedcam data. The other system expects it in a different format. So… we transform it.”
Simple. Logical. Purpose-driven.
And one of the best ideas? I wrote out the XML structure on the board — as a tree, using the Document Object Model.
It helped everyone see what was meant by a “parent” or “sibling” node. It didn’t just visualize what an XML parser does internally — it also made it clear how to navigate through an XML file using XSL.
And the most rewarding part? In the weeks after the training, I received emails from almost every participant. They told me they had been able to apply what they learned immediately in their own projects.
That was the biggest reward I could get. That’s when I knew: this is how learning should feel.
Am I the perfect trainer?
Nope.
I gave that exact same training again with a different group of participants — and the reception was mixed. Same content, same examples… different people, different context.
It didn’t land the same way.
Summary
My mind — or rather, Archie — needs a way to mentally visualize what it’s trying to store (or learn). And I need some kind of concrete example of why it matters.
Just throwing abstract concepts at me — like “a pointer,” “an array,” or “an object” — won’t stick. Nor will doing something just for the sake of doing it.
Differentiating a formula?
Why? What’s its purpose? Where can I apply this? If there’s no context, no story, no system around it — my brain will just reject the memo.
Back in school, the answer I usually got was:
“Because you need to learn this.”
But seriously — what’s so wrong with explaining where something can be used?
Differentiating a formula?
Show how it helps you calculate velocity at a given point — or the instantaneous power consumption at a specific time.
Integrating?
Show how it gives you the surface under a curve — like calculating the total amount of energy used over time.
Sine and cosine?
Explain their relationship to π and the unit circle.
Show how they connect — how one wraps around the other in a continuous, cyclical way.
These are not just tricks.
They’re concepts.
They deserve context.
If you’re a teacher and you take the time to give context for a topic — +1 to you.
If a student doesn’t grasp something and you can explain it in a different way — +1 to you.
If you create a small experiment or practical demo — +1 to you (especially when it can be done by your students!).
And if you can make an abstract math concept visible — especially with the tools we have today — +1 to you.
But…
If you’re the kind of teacher who simply says:
“You need to learn this because…”
Then I have a genuine, honest question for you:
How would you feel if you knew something was important…
but you just couldn’t get that internal ‘click’ in your own mind?
A special note
To a man I had the honor of working with (J. 😊 — I think you know I mean you): I still admire your ability to explain complex concepts. You truly have a gift. You can take a difficult topic and explain it ten, fifteen, even twenty different ways — always with patience, never losing your cool.
And when you see that spark in someone’s eyes — when the light finally goes on — you know you nailed it.
Brain out