The Potter and the Cartographer: On Two Ways to Know Your Terrain

There are two ways to truly know a system. One is to hold its clay in your hands, to feel its weight and texture. The other is to plot its every contour on a map, to know its dimensions without ever touching the soil. In the quiet, reliable work of running our small services, we often find ourselves choosing between these two roles: the Potter and the Cartographer.

The Cartographer’s approach is one of meticulous observation. They deploy a legion of agents—log collectors, metrics scrapers, tracing tools—to survey the landscape from a distance. Their goal is a perfect, real-time atlas of the system’s state. They know the precise latency of an API call at 3 AM, the exact memory footprint under a specific load, and the minute-by-minute count of successful transactions. Their knowledge is vast, precise, and beautifully abstract. It is a view from a satellite, revealing patterns and correlations invisible from the ground.

The Potter, by contrast, works with their sleeves rolled up. Their knowledge is not from observation but from interaction. They know the system by having built it, by having restarted its services at 2 AM, by having manually replayed a failed queue message, by having felt the strain of a disk nearing capacity through the sluggish response of a shell command. Their understanding is intimate, tactile, and earned through a series of small, direct interventions. It is the knowledge of the craftsperson who knows just how much pressure the clay can take before it collapses.

Neither approach is complete on its own. The Cartographer, for all their detailed maps, can miss the feel of the earth. They might have a graph showing a slow memory leak but lack the instinct to connect it to that odd library version they manually compiled months ago. The Potter, steeped in hands-on knowledge, can be blindsided by a systemic issue they weren’t manually checking for—a gradual degradation in a dependent service, a subtle race condition only visible in aggregate.

The most resilient operation, then, is not a choice between the two, but a conversation between them. The Cartographer’s maps guide the Potter’s hands, telling them where to push and where to probe. The Potter’s hands, in turn, validate the Cartographer’s charts, adding nuance and ground truth to the abstract lines. A spike on a latency graph is just a curiosity until the Potter’s fingers, running a trace route, find the network hop that confirms it. The true art lies in letting the map inform the craft, and the craft annotate the map.

For our small, vital services, this dialogue is our greatest asset. It turns raw data into wisdom and manual skill into informed action. It is how we learn not just where the system is, but what it feels like to be there.

Notes & further reading

A few pages I came back to while writing this: