Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had an amazing week!
Why is every tech company switching to this app?
Teams at Vercel, Brex, Replit, Linear, Ramp, and Intercom all use it. Brex is saving 427 hours a week with it. And Vercel's CEO said there's no going back.
It's called Granola, so when I heard all these companies were using it, I had to try it.
Granola records your meetings automatically and transcribes everything in the background while you take notes like normal. No bot joining your call, no “recording in progress” sound, nobody knows it's there.
After the meeting, it takes your notes and the full transcript and turns them into a clear summary of the meeting and what you actually need to do next. Granola also has templates so you can get different summaries depending on the meeting. Plus, you can chat with it after and ask questions about the meeting.
Oh, and you can share that summary with your team. Because let's be honest, they forgot too.
How Does Google Maps Find The Fastest Route?
You know, I’ve never once stopped to ask how Google Maps comes up with the estimated time. I just see that it takes a few minutes and follow the route like the good boy I am.
But under the hood, a routing system has to solve a genuinely hard optimization problem across a huge road network while accounting for road rules, travel mode, traffic, closures, toll preferences, and other constraints.
And it has to return a useful answer fast enough that you don’t throw your phone out the window.
The foundations come from decades of graph theory, shortest-path algorithms, spatial data structures, prediction systems, and large-scale infrastructure.
Let me explain how sick Google Maps is and why it’s one of the best technologies ever.
How Google Maps picks a route
Before we get into the cool algorithms, we need to talk about how Google Maps sees the world.
As you all know, computers don’t have eyeballs like us, so they need a different way to “see.”
A routing engine models the road network as a graph rather than treating the pretty map image you see on screen as the thing it searches.
It sees a graph (it’s a cool data structure that every programmer should know.)
Weighted graph example
Depending on the routing model, nodes can represent intersections or important points in the road network.
Edges represent traversable road segments or connections between those points.
Each edge can have a cost based on what the route is optimizing—often estimated travel time, but distance, restrictions, tolls, traffic, turn penalties, or other preferences can influence whether an edge is usable or how expensive it is.
What the heck is a weight?
When a graph has a weight, it’s called a weighted graph (crazy name I know), and a weight is usually just a number.
For a shortest-path algorithm, lower total cost is better—but “cost” does not have to mean literal money or even just distance.
Real routing systems can incorporate information such as:
estimated traversal time and speed
one-way and turn restrictions
road closures and access rules
tolls/highways/ferries and route preferences
travel mode (driving, walking, biking, transit, etc.)
live and historical traffic when traffic-aware routing is enabled
road surface (paved vs. unpacked dirt)
turn difficulty
toll costs
speed limits
one-way restrictions
ferry crossings
your personal preferences like "avoid highways.
So “find me a good route from A to B” becomes a graph-search problem whose objective and constraints depend on the route settings—not always simply “pick the geometrically shortest road.”
So "find me the fastest route from A to B" becomes:
Find the path through this giant graph with the lowest total weight.
Sounds simple right? Well the idea is simple, the hard part is the terrifying scale.
The algorithm that made this idea possible
It's 1956 in Amsterdam. A Dutch programmer named Edsger Dijkstra is out shopping with his fiancée. They get tired. They sit down at a café.
No laptop. No notebook. No pencil.
And in 20 minutes, he designs one of the most important algorithms in computer science history.
All in his head btw.
We call it Dijkstra's Algorithm.
Dijkstra’s algorithm is still one of the foundational shortest-path algorithms every programmer should know. It’s a great mental model for understanding routing—even though production map systems use far more engineering than one textbook algorithm.
What a productive coffee break.
Dijkstra’s Algorithm
Here's how it works:
Start at your origin node (starting point). Assign it a cost/weight of 0.
Assign every other node a cost/weight of infinity since you haven't found a path there yet.
Look at all your current node's neighbors.
Update their costs if you found a cheaper way to reach them.
Move to the unvisited node with the lowest cost.
Repeat steps 3-5.
Stop when you hit the destination.
With non-negative edge weights, Dijkstra’s algorithm can guarantee a minimum-cost path once the destination is finalized.
Sounds a bit complicated (especially if you don’t know graphs), but it’s honestly something we usually do without even thinking.
You don't take random roads home, you take the ones that feel most promising. Dijkstra just turned that instinct into an algorithm.
Here's what that looks like in code:
import heapq
def dijkstra(graph, start, end):
# Priority queue: (cost, node)
queue = [(0, start)]
visited = {}
while queue:
cost, node = heapq.heappop(queue)
if node in visited:
continue
visited[node] = cost
if node == end:
return cost
for neighbor, weight in graph[node].items():
if neighbor not in visited:
heapq.heappush(queue, (cost + weight, neighbor))
return float('inf') # No path foundThe catch isn’t that Dijkstra “doesn’t scale” at all. The problem is that searching an enormous road graph from scratch for every request can explore far more of the network than necessary, so production routing engines use additional indexing, preprocessing, heuristics, partitioning, caching, and other optimizations.
The scale problem
Interstate map for the US.
There are millions of homes, restaurants, streets, sideways, etc.
If you run Dijkstra on that from scratch every time someone searches for a route, depending on the distance, it would check thousands to even millions of possible routes. This could take seconds or even minutes.
For Google, seconds aren’t fast enough, it needs answers in milliseconds.
Two classic ideas that help explain how large route planners can search faster are A* and hierarchical/preprocessed routing. These are useful algorithms to learn, but Google does not publicly document its full current production routing stack as simply “Dijkstra + A* + contraction hierarchies.”
Dijkstra explores every direction equally because it has no idea if we’re actually getting closer to the destination.
A* (A-star) is a shortest-path algorithm that combines the cost already traveled with a heuristic estimate of the remaining cost.
You can think of it as Dijkstra-style search with extra information telling the algorithm which frontier nodes appear more promising.
For geographic routing, a heuristic might use straight-line/geodesic distance or another lower-bound estimate of the remaining trip cost.
With an appropriate admissible heuristic (and the usual conditions/implementation details for optimal A*), the heuristic can guide the search without sacrificing optimality.
Dijkstra expands nodes based only on cost-so-far. A* can prioritize nodes that also appear closer to the goal, which often means exploring much less of the graph.
That can produce the same optimal result while doing substantially less search when the heuristic is informative.
Notice the difference in visited squares, that’s the important part.
2. Hierarchical and preprocessed routing
This is where it gets big brain.
When you're driving from city to city, you'll spend maybe 2% of your time on side streets. The other 98%? Highways.
So why should the algorithm waste time evaluating every small street?
Contraction Hierarchies are one famous example of preprocessing a road graph so later shortest-path queries can skip large amounts of low-level detail:
Preprocess nodes in an importance order
Add shortcut edges so shortest-path distances are preserved when less-important nodes are bypassed
Answer later route queries using the resulting hierarchy instead of blindly exploring the raw graph
The broad idea is useful beyond one specific algorithm: spend computation ahead of time organizing a mostly static road network so interactive route queries have much less work to do.
Modern routing engines use a variety of graph preprocessing and acceleration techniques. Contraction Hierarchies are an excellent example to study, but they should not be treated as a confirmed description of Google Maps’ current proprietary implementation.
The traffic problem
The road graph gives you possible routes and baseline travel costs. Traffic-aware routing makes the cost of those roads time-dependent: a road that is great at 2 a.m. might be miserable at 5 p.m.
Current traffic can change quickly, while historical traffic patterns help estimate what conditions are likely to look like around a requested departure time.
Google’s public routing documentation describes route calculations that can incorporate live traffic, historical traffic patterns, route preferences, toll information, travel mode, and other configuration. Google does not expose every internal signal or algorithm used to turn those inputs into consumer Google Maps routes.
For the useful developer mental model, treat traffic as another source of changing edge costs: the estimated time to traverse a road segment can rise or fall as conditions change.
That means the “best” route can change even when the physical road network does not. Traffic-aware routing can affect both the route selected and the predicted duration.
At Google’s scale, this becomes a prediction-and-routing problem layered on top of the graph-search problem—not simply a static shortest-path calculation.
More data can improve traffic models, but raw user count is not the same thing as having one clean “moving data point” per user. Signals have to be aggregated, filtered, modeled, and combined with other information.
So the useful takeaway is: better traffic inputs and prediction models can produce better edge-cost estimates, which can improve route selection and ETAs.
Traffic-aware routing can combine signals such as:
historical traffic patterns
current traffic conditions
road restrictions, closures, and route preferences
prediction models that estimate how conditions may change during the trip
Historical traffic patterns — Tuesday at 5pm always has bad traffic and Google already knows that
Road sensor data from municipalities
User-reported incidents — accidents, construction, road closures
ML models predicting conditions 30 minutes ahead, not just now
That’s why an ETA or recommended route can change mid-drive as new information changes the estimated costs of the available paths.
The system can recompute or update the route when the cost model changes enough to make another path preferable.
Which means every time you get directions, you're using 70 years of computer science.
Pretty cool, honestly.
Oh right, you’re a nerd. Here’s some cool resources
A* Search Explained — the best visual explanation I've found
Contraction Hierarchies - Great explanation that showcases the benefits
If you want to keep learning
Data structures and algorithms explained — graphs, pathfinding, and algorithmic efficiency are the computer-science foundation behind this entire routing problem.
Geohashing explained — another trick location-based systems use to turn latitude and longitude into searchable regions.
5 system design resources — go deeper on scaling, distributed systems, caching, databases, and architecture.
Thanks to everyone who submitted!
SiddhantSharma313, gcavelier, Coducks2, Neverever1705, Hbear10, hamooo21112655, Ayushman-Mandhotra, KArtoffelUTE, carolina-jung, cwyner, and Manzolillom!
Seven Boom!
Create a function that takes an array of numbers and for every 7 found, add one "Boom!" to your result. If no 7 is found anywhere, return "there is no 7 in the array".
Examples
sevenBoom([1, 2, 3, 4, 5, 6, 7])
output = "Boom!"
// One 7 found → one "Boom!"
sevenBoom([8, 6, 33, 100])
output = "there is no 7 in the array"
// No 7s found anywhere.
sevenBoom([2, 55, 60, 97, 86])
output = "Boom!"
// 97 contains one 7 → one "Boom!"
sevenBoom([7, 77, 100])
output = "Boom! Boom! Boom!"
// 7 has one 7, 77 has two 7s → three totalNotes
Check every digit of every number, not just whether the number equals 7.
How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
