Debugging the Body, Healing the Code
Parallels between debugging software and manual therapy. Both follow the same pattern: symptom, hypothesis, test, adjust. The body as codebase.
A friend who does remedial massage told me something that changed how I think about debugging. A client came in with shoulder pain. She spent the first twenty minutes working on the client's hip.
"The shoulder wasn't the problem," she said. "The hip was locked up, which tilted the pelvis, which curved the spine, which forced the shoulder to compensate. By the time it hurt, the shoulder had been covering for the hip for months."
I was halfway through a production incident at work. A service was timing out. I'd been staring at the service's code for two hours. Turns out the problem was in a database connection pool three services upstream.
Where does it hurt
The first rule of both disciplines is the same: the symptom is not the cause. The place where it hurts is rarely the place where it's broken.
In manual therapy, this is called "referred pain." The nervous system is imprecise about reporting the location of problems, especially chronic ones. Your knee hurts, but the issue is in your ankle. Your head aches, but the tension is in your jaw. The body routes pain signals through shared nerve pathways, so by the time the signal reaches consciousness, its return address is wrong.
Software does the same thing. A timeout error in Service A doesn't mean Service A is slow — it means something Service A depends on is slow, or something that depends on is slow, or the network between them is degraded, or the load balancer is misconfigured, or the DNS resolver is caching a stale address. The error message tells you where the pain surfaced. It tells you nothing about where the problem lives.
Both disciplines require the same first step: resist the urge to treat the symptom. Don't massage the shoulder. Don't restart the service. Ask: what else is connected to this?
Following the stack trace
A good manual therapist doesn't start with the complaint. They watch you walk. They ask you to raise your arms, bend your knees, turn your head. They're building a picture of how your whole system moves before they touch anything.
This is triage. It's the same thing a good engineer does before reading logs — they check the dashboard. Not the specific metric that's alarming, but the whole picture. CPU, memory, network, disk, error rates, latency percentiles, deployment history. They're looking for the pattern, not the data point.
Then both do the same thing: they form a hypothesis and test it.
The therapist presses a spot and asks, "Does this reproduce the pain?" The engineer adds logging and asks, "Does this reproduce the error?" If yes, you're getting closer. If no, revise the hypothesis, move to the next suspect.
The skill isn't in knowing where to press first. It's in knowing how to revise your hypothesis when you're wrong without getting attached to your first guess. Beginners in both fields tend to lock onto their initial theory and keep pressing the same spot harder. Experts move on.
The referred pain problem
The hardest bugs and the hardest injuries share a characteristic: the causal chain is long and crosses boundaries.
In the body, the chain might cross from muscular to skeletal to nervous to fascial systems. A tight psoas (deep hip flexor) can cause lower back pain, which causes neck tension, which causes headaches, which causes jaw clenching, which causes tooth pain. A dentist sees a dental problem. A neurologist sees a neurological problem. A physiotherapist sees a musculoskeletal problem. They're all looking at the same chain from different points.
In software, the chain might cross from application to infrastructure to network to third-party dependency. A memory leak in a library causes garbage collection pauses, which cause request latency spikes, which cause connection pool exhaustion, which cause timeout errors, which cause retry storms, which cause cascading failures across the entire system. Each team sees their component's symptom and files a separate incident report.
The solution in both cases requires someone willing to follow the chain past the boundary of their own expertise. The massage therapist who understands biomechanics and nervous system physiology. The engineer who understands application code and infrastructure and networking. The generalist who can trace the referred pain back to its source, even when the source is in someone else's domain.
This is why the most effective debuggers I've known are not the deepest specialists. They're the broadest systems thinkers — the ones who can hold the whole causal chain in their head and follow it across boundaries without stopping at the edge of their comfort zone.
Systems that heal themselves
The body has a remarkable property that software mostly lacks: it heals. Given rest, proper conditions, and the removal of the aggravating factor, most injuries resolve on their own. The therapist's job is often not to fix the problem but to create the conditions under which the body can fix itself — release the tension that's preventing natural movement, restore range of motion, give the system room to do what it already knows how to do.
There's an analogy here to a certain style of engineering that I think is undervalued. Instead of writing code to handle every failure mode, design the system so it can recover from failures on its own. Circuit breakers. Exponential backoff. Self-healing clusters. Graceful degradation. The engineering equivalent of "remove the thing that's preventing natural function and let the system do the rest."
The therapist who tries to force the body into correct alignment often makes things worse. The engineer who writes a complex workaround for a systemic problem often makes things worse. Both are imposing a solution instead of enabling one.
The better question, in both domains, is not "how do I fix this?" but "what's preventing this system from fixing itself?" Remove the impediment. Create the conditions. Trust the system.
It won't always work. Some injuries need surgery. Some bugs need a rewrite. But more often than most people expect, the system already contains the solution — it just needs permission to apply it.
What's preventing your system from healing itself?