The Messy Path Behind Real Learning
Why building one small thing end to end teaches more than following a perfect learning path
Circling Around a Familiar Problem
I’ve been working on some map-based data visualisation recently.
To be fair, this isn’t completely new to me. Over the past few years, I’ve done similar work before — playing with Blender and DEM data, experimenting with 3D terrain and relief. I did manage to get some results, but none of them felt worth sharing. I roughly understood what was happening, but not deeply enough to feel confident about it.
Looking back, those attempts were more like touching the surface. I knew which buttons to press, but I didn’t really have a clear mental model of what I was doing or why things worked the way they did.
This time, something felt different.
Learning Rarely Follows a Straight Line
What I realised — again, but much more clearly — is that learning is not linear, especially when you enter a domain you’re less familiar with.
It’s unlikely that there’s a clean, well-structured path that tells you exactly what you need to learn and in what order. And even when such a path exists, it’s often boring, abstract, or disconnected from what you actually want to build.
You don’t really learn a new domain by following a syllabus. You learn by getting stuck, trying things, backing out, and exploring different directions. That messiness isn’t a flaw in the process — it is the process.
A Small End-to-End Journey Works Better
What consistently works better, in my experience, is following a simple but complete, end-to-end journey.
Build one thing. Finish it. Then iterate on top of it.
Not perfectly. Not optimally. Just end to end.
This matters because learning isolated concepts without context rarely sticks. When you build something end to end, every detail suddenly has a purpose. You’re no longer learning “because you should”, but because the next step depends on it.
Inspiration, and the Illusion of the Final Result
Recently, I came across some truly beautiful cartography artwork from Viz Art. Even if you’re not interested in maps or GIS, the work itself is worth seeing.
At first, I assumed these pieces were designed physically, printed, and then scanned or photographed into a digital format. And on the other hand that sounds like too much effort, or maybe they have some secret weapon I didn’t know (the unknown unknown).
Anyway, that idea stayed in my head for a while as a small puzzle.
Then one night, while watching a YouTube video about a completely different topic, I noticed something interesting. The creator started from an old map, combined it with DEM data, and stitched everything together to produce a 3D relief.
That was the missing piece for me.
What we usually see online is only the final result — the clean render, the polished artwork. What we don’t see are the hundreds of failed attempts, wrong assumptions, broken files, and abandoned paths behind it.
That invisible exploration is where the real learning happens.
The Messy Reality of Actually Doing the Work
Watching videos on YouTube is usually not the real learning.
To really learn something, you have to do it on purpose: typing, clicking, drawing, mimicking — often clumsily. You will get blocked. You will get frustrated. You will Google things, ask AI, and still find that nothing works.
And then, sometimes, the next morning, you suddenly see a way forward.
For a single visualisation, there are many things involved: colour schemes, 3D rendering, GIS concepts, DEM data, image editing. That means many tools — QGIS, Photoshop (or GIMP), Blender — and each of them has hundreds of details.
In QGIS alone, you run into concepts like CRS, extent, layers, shapefiles, raster operations, clipping, reprojection, GeoTIFFs, pseudo-colour. In image editing, there are hues, masks, channels, blending. In Blender, there are materials, modifiers, subdivision, textures, lights, rendering settings.
There is some overlap, but most skills don’t transfer directly. On top of that, hardware limits become very real once you start working with large DEM files or heavy subdivisions.
Trying to understand everything upfront is overwhelming — and unnecessary.
Name the Process First, Then Fill the Gaps
What helped me most was to stop focusing on mastering tools and instead focus on establishing a process.
I could roughly describe the work in three stages:
preparing the data
preparing the texture
rendering the result
That’s it.
Once you can name the stages, you have a mental model. Without it, it’s easy to get dragged into details too early and lose sight of the goal. At this stage, you only learn what’s necessary to move forward.
Later, once the pipeline exists, curiosity naturally kicks in. You start asking better questions: how DEM data is stored, how colour actually works, how subdivision affects geometry, how light changes the final result.
This is when deeper learning makes sense — reading documentation, experimenting deliberately, asking experienced people, reading books or blog posts. Teaching others is especially powerful: the moment you try to explain something, you discover the holes in your own understanding.
Learning never happens in order. You pick things up here and there — from tutorials, random videos, blog posts, or conversations. That’s completely normal.
When you catch yourself thinking “there must be a better way to do this”, mark it. Finish the prototype first. Then come back and go deep on that one topic.
Learning is not linear. But if you keep moving forward with a clear, end-to-end journey, the knowledge compounds quietly.