Last December, I found myself gripping the steering wheel a little tighter than usual. My Cousin and I were winding through the forest roads around Mount Kenya, you know, the kind of roads that make you question whether you're still on a road at all. Red murram dust everywhere, branches scraping the car windows, and the occasional potholes filled with murky waters.
But here's what blew my mind: my phone, perched on the dashboard, was calmly showing me the route on Google Maps. Not just showing me a vague "you're somewhere in this green blob" situation, no, it was displaying the exact footpaths, the shortcuts between villages, even those sketchy-looking turns near through plantations that somehow were supposed shave off 10 minutes from our journey.
There were no paved roads. No street signs. Half the time I wasn't even sure we were still on what qualified as a "road." Yet Maps knew. It knew which fork to take, which path was faster, and - this is the kicker - it updated in real-time as we drove, adjusting for the route that would get us to our destination quickest.
I remember admitting to my cousin how impressive I thought the technology behind google maps was. The fat that those who built it may have never stepped foot in Kenya, let alone those sketchy rural roads in Mt Kenya. "How does this thing know?" I wondered. That evening, back at home - yes we made it back home, phew! I went down a rabbit hole trying to figure out how Google Maps actually works.
That's when I met Dijkstra.
Turns out, behind that smooth blue line on your screen is some seriously clever math. At the heart of many navigation systems is something called Dijkstra's Algorithm—a method invented way back in 1956 by a Dutch computer scientist named Edsger W. Dijkstra.
The algorithm solves one deceptively simple problem:
"What's the shortest path from point A to point B in a network of connections?"
That network could be:
- Roads and footpaths (like the ones through Mount Kenya's forests)
- Flight routes between cities
- Computer networks routing data packets
- Even game maps where characters need to find their way around obstacles
The beauty of it? Whether you're navigating through The Central Business District grid in Nairobi or a maze of forest trails in rural Kenya, the underlying logic is the same.
"How Does It Actually Work?" I can hear your curious minds ask.
Let me break it down without getting too technical.
Imagine you're standing in your apartment, desperately craving mandazi from that one kiosk that makes them perfectly crispy on the outside and fluffy on the inside. But here's the thing: you could take the main road (longer but smooth), cut through the dusty shortcut behind the church (shorter but you might run into that neighbor who talks for 20 minutes), or loop around past the boda boda stage (scenic but chaotic). Multiple paths, multiple trade-offs.
Here's what Dijkstra's Algorithm does:
Treat every location as a node (like dots on a map): Your apartment, the church, the boda stage, Mama Njeri's kiosk with the legendary mandazi—all nodes.
The paths between them are edges with a "weight": That weight could be distance, time, or even "probability of getting stuck in a conversation." The church shortcut might be shorter but slower because you're dodging chickens and greeting everyone. The main road might be longer but you can power-walk uninterrupted.
And maybe I'll trust that route through the forest a little bit more, unless I have a tecno phone.
