I hit a wall at thirty-six that I couldn't explain.
For two months, a system I'd built—one that had been printing money, running smoothly, seemingly bulletproof—just... broke. No warning. No obvious bug. The inputs hadn't changed, the code hadn't changed, but the outputs went sideways. I stared at dashboards until my eyes burned, checking logs like a doctor checking pulses, finding nothing.
That's when I realized I'd been "acting exhausted" for years. Not physically tired—though I was that too—but something deeper. Like I was running software my hardware couldn't support.
The Monk and the Copycat
There's this scene in Demi-Gods and Semi-Devils that I keep coming back to. Jiumozhi—the brilliant monk who mastered seventy-two Shaolin techniques perfectly, down to the muscle memory. Every punch, every stance, flawless execution. And then there's the Sweeping Monk, who barely knows any martial arts but understands the Buddhist philosophy underneath them.
The Sweeping Monk warns Jiumozhi: without the framework, without the why behind the movements, the conflicting energies will eventually tear him apart. He has the hands (手熟) but not the vision (见识).
I read that differently now. Jiumozhi wasn't just a cautionary tale about arrogance. He was a portrait of every professional who gets really good at their job without understanding the broader game they're playing. You're a master of Excel macros in an industry that's being automated. You're a virtuoso copywriter in an era of LLMs. You can execute circles around everyone, but you're executing the wrong play.
When your skill outpaces your vision, you become dangerous to yourself. Like a kid who learns to drive a sports car before they understand traffic laws—you've got the horsepower, but no map. Eventually, you hit something.
The Architect Who Couldn't Code
But I had the opposite problem in 2009. I'd talked my way into being a software architect—high vision, high-level thinking, big system design—but my actual coding skills were rusty, maybe Level 2 on a good day. I was designing buildings I couldn't personally construct.
The imposter syndrome was suffocating. Until my boss at the time—a quiet genius—explained something that saved my career. He said we weren't building one thing. We were building two layers.
The top layer was the concept: the "virtual function," the abstract idea of what we needed. Like the concept of a chopstick—the nameless form that lets you pick up food.
The bottom layer was the instantiation: the actual bamboo chopsticks, the repetitive code, the grind.
Laozi apparently said something similar: "The name that can be named is not the constant name." I think he was talking about abstraction layers. By separating the vision from the execution, we turned software development from an art form into an assembly line. I designed the energy flow; the junior developers provided the hands. The system commoditized the labor while elevating the design.
It worked. Until it didn't.
The Donkey's Dilemma
Ming Dynasty philosopher Wang Yangming had this idea: 知行合一—the unity of knowledge and action. You can't improve your vision without testing it in reality, and you can't improve your execution without expanding your understanding. They bottleneck each other.
I think about this when I see people grinding eighty-hour weeks, learning nothing. A donkey can walk a hundred thousand miles, Wang Yangming might say, but without insight, it's just wearing down its hooves. You see these guys in every industry—ten years of "experience" that's really one year repeated ten times. High execution, static vision. They hit their ceiling hard around age forty and wonder why the younger people are flying past them.
But if you can keep the loop tight—if every action informs your vision and every vision tests itself through action—you accelerate. And if you have resources—money, team, technology—you can scale that loop. You use other people (or algorithms) as your hands and feet, gathering experiential data while you remain the central processor, the brain updating its model of reality in real-time.
That's what I thought I was doing at thirty-six. I thought I'd built the perfect feedback loop.
When Newton Breaks
Then the system failed for two months, and I couldn't fix it.
That's the Newton versus Einstein moment. Newton's physics work perfectly—until you're moving near the speed of light, or dealing with the very small, or the very massive. Then Newton's laws don't just become inaccurate; they become actively wrong. You need Einstein.
When your optimized system breaks and you can't find the bug, it's not because you made a mistake. It's because you've hit the boundary of your known universe. Your current combination of vision and execution has collided with a macro-environment containing variables you haven't mapped yet. Hidden dependencies. Second-order effects. The stuff that doesn't show up in the logs because it's outside your measurement framework.
I hadn't failed. I'd just discovered the edge of my laboratory.
The exhaustion I felt—the "acting exhausted"—wasn't from working too hard. It was from running a mental operating system that was incompatible with the reality I was trying to process. Like Jiumozhi, I'd accumulated techniques without the underlying framework to hold them together. The conflicting forces were tearing me apart, and the only cure was to step back and upgrade my vision—to find the Einstein theory that explained what Newton couldn't.
That's the brutal truth about burnout: sometimes you're not tired. You're just running the wrong version of yourself for the current level of the game.
