Ten functions are carrying your entire company. Name them.

Here's a thought experiment to run at your next engineering meeting. It takes ninety seconds and it is, fair warning, a little cruel.

1. Ask everyone to take out a piece of paper. No laptops. That's the cruel part.
2. Ask them to write down the ten functions that carry the most production traffic in your system — the actual, specific, named functions through which the most calls flow on a normal Tuesday.
3. Then ask for a second number: what share of ALL production calls do those ten functions handle, combined?
4. Collect the papers. Compare.

I can tell you what happens, because the failure mode is nearly universal. The lists overlap on maybe three entries — usually the login handler and a couple of obvious API endpoints. The share estimates range from 10% to 80%. And at least one senior engineer writes down a function that was deprecated last year. Your team — your good, capable, expensive team — cannot name the parts of the system that do most of the work. Nobody can, because nobody has ever seen the map.

Your codebase is a city, and you've never seen its traffic

Look at any city's road network and you see thousands of streets. Now look at the same city's traffic and you see something completely different: a tiny skeleton of arterials carrying overwhelming majorities of all vehicle-miles, surrounded by thousands of residential streets that see twelve cars a day. The map of what exists and the map of what's used are two different maps — and every consequential decision (where to repave, where a closure becomes a catastrophe, where to put the hospital) depends on the second one.

Codebases work the same way, and more extremely. In CodeNSM's own fleet telemetry, production call load is savagely concentrated: a small minority of functions reliably carries the overwhelming majority of all calls — a pattern strong and consistent enough that we pre-registered it as a formal research hypothesis rather than just asserting it in blog posts. This is Pareto's old 80/20 shape, except in function traffic it's often ruder than 80/20.

This shouldn't actually surprise anyone. Adam Tornhill's Your Code as a Crime Scene demonstrated the same concentration in a different dimension: development activity clusters in a few hotspot files, and those hotspots are where the defects and the costs live. Change concentrates. Traffic concentrates. Everything about software concentrates — except, hilariously, attention, which your org distributes by whatever the roadmap says this sprint.

Okay, but why does the map matter so much?

Because nearly every engineering decision has a hidden multiplier on it — traffic — and right now that multiplier is invisible, so everything gets treated as if it were multiplied by one. Walk through what the hot-path map changes:

Code review stops being flat. Today, a PR touching a function that handles 40% of production calls gets the same fifteen-minute skim as a PR touching a settings page. That is exactly as sane as a city giving the same permit process to "repaint a garage" and "close a bridge." A team that knows its arterials reads those diffs differently — more eyes, slower merge, a rollback plan. A team that doesn't, finds out which kind of street it was after the deploy.

Testing effort finds its denominator. Every team "should write more tests" the way everyone "should exercise more" — the advice fails because it has no priority order. The hot-path map IS the priority order: coverage on ten arterial functions protects more revenue than coverage on four hundred side streets. Tornhill and Borg's Code Red research found that low-quality code carries up to fifteen times more defects than healthy code; now imagine where you'd most want that multiplier NOT to land. Right. On the arterials.

Performance work stops being archaeology. Optimizing a function nobody calls is a hobby. Optimizing a function on the hot path is leverage — a 10ms improvement multiplied by millions of calls. Without the map, engineers optimize what they last touched or what profiles interestingly on their laptop, which is how companies end up with beautifully tuned batch jobs and a checkout arterial nobody's looked at since 2023.

On-call stops being uniform dread. An incident in a side-street function is a ticket. An incident in an arterial is a war room. Knowing which is which BEFORE the pager goes off is the difference between triage and panic.

"We'd know. We have APM."

You have request monitoring. Your APM ranks endpoints, and endpoints are useful — but an endpoint is a front door, not a hallway. Behind "POST /api/checkout" sits a call tree of dozens of functions, and the concentration happens INSIDE the tree: the same validation function, the same serializer, the same permissions gate reused by thirty endpoints, quietly aggregating more traffic than any single endpoint shows. The arterial is often a function no product manager has ever heard of, with a name like resolve_context, sitting under everything. Endpoint dashboards structurally cannot surface it, because it doesn't belong to any one endpoint. (Building the per-function traffic map — every function ranked by observed production calls, updated continuously — is precisely the hot-path view CodeNSM maintains; the first time a team sees theirs, someone always loses a bet.)

And the deeper thing about arterials: they're load-bearing precisely because they're stable and boring, which means git shows nothing happening there, which means every activity-based instrument your org uses files your most important code under "quiet." The concentration of importance is real; the visibility of importance is inverted.

Your arterials move (that's the other problem)

Suppose you did the archaeology once — a heroic engineer spent a week with logs and a profiler and produced The List. Great! Frame it. It's already aging. Hot paths drift with the business: a new enterprise customer routes 30% of traffic through a code path that was a side street last quarter; a product pivot demotes last year's arterial to a museum piece; a caching change quietly reroutes half the city overnight. This is Lehman's evolution dynamics applied to traffic instead of structure — the system you're mapping is required, by its own success, to keep redrawing itself under your pen. Which means the hot-path map isn't a document. It's a FEED. A one-time audit answers "what were my arterials in Q1," which is a piece of history, not an instrument. The question that protects you is "what are my arterials right now, and which ones are new" — and that question can only be answered by something that never stops counting.

The two-list exercise

One more thought experiment, this one for you rather than your team. Make two lists:

1. List A: the parts of the codebase your organization discussed most this quarter — in planning, in retros, in the tech-debt slide.
2. List B: the ten functions that actually carried the most production load this quarter.

You can't fully write List B, which is the point of this whole post. But even the attempt is clarifying — because whatever's on List B, one thing is almost certain: it barely overlaps List A. Organizational attention follows novelty, incidents, and roadmaps. Traffic follows none of those things. The most important code in your company is, right now, the code nobody is talking about.

A city that doesn't know its arterials isn't managing traffic; it's guessing. Score yourself below — one point per "no" — and see how much of your city is currently unlit.