Passion Is the Hot Path

There’s a common view that doing what you love is a luxury — that under the pressure of just surviving, or of competing, you don’t really get to choose. I used to believe roughly that. Then I went back to Hume, and realized he had already written down the most serious version of this argument 300 years ago. Translated into a software engineer’s language, the whole thing becomes unusually clear.

The line from Hume

In Book II of A Treatise of Human Nature (1739), David Hume (1711–1776) wrote one of the most quoted — and most under-read — sentences in modern philosophy:

Reason is, and ought only to be, the slave of the passions.

By passions Hume doesn’t mean what English now reads as “passion” — fire, intensity, romance. He means something closer to emotions, desires, motivations — everything that makes you want, avoid, approach, or leave. His core point lands in three layers:

1. Reason on its own cannot move you. It can tell you A implies B and B implies C, but it cannot tell you that you ought to want C.
2. What actually moves you is some emotion or desire. The “wanting” itself isn’t the product of reasoning.
3. Reason’s job is to find the path. Once you already want something, reason figures out how to get there.

To push the point all the way, Hume puts down a sentence that has unsettled readers ever since:

‘Tis not contrary to reason to prefer the destruction of the whole world to the scratching of my finger.

At first read it sounds like a defense of cruelty. It isn’t. It’s making a very clean distinction: choice itself is not reason’s job. Reason can evaluate whether a means is effective. It cannot, on its own, say whether an end is “right.” Something has to be wanted first; only then does reasoning have anything to work on.

Re-reading Hume in a programmer’s vocabulary

I write software for a living, so every time I read that passage I find myself silently re-translating it. The cleanest mapping I’ve found is this:

1. Emotions are the instruction set — the things the CPU actually runs. Hunger makes you eat. Tiredness makes you sleep. Seeing someone you like makes you move closer. These aren’t decided; they’re triggered directly by the underlying hardware.
2. Reason is a high-level language. Code written in C++, Python, or TypeScript isn’t executed by the CPU directly — it has to be compiled into machine instructions first. The same is true for any chain of rational argument: to actually run, it has to bottom out in something you already care about.

The corollary is the part that matters: any rational argument that’s going to change what you do has to, at some step, plug into an emotion you already have. If it never reaches that layer, it stays on the page.

“You should sleep earlier — it’s good for your health.” — a perfectly correct piece of high-level code. The CPU does not execute it.

“I’m meeting someone tomorrow who actually matters to me, and showing up with circles under my eyes on the first meeting would humiliate me, and I hate being humiliated.” — code with an emotional anchor. The CPU executes it.

The semantics are the same. The difference is whether it compiles all the way down.

What a good system looks like

The interesting part of the analogy starts here.

How is a well-written software system built? Roughly in three steps:

1. Write the whole thing in a high-level language first. C++, Python, TypeScript — whichever lets you move fastest. The goal here is clarity, maintainability, easy evolution. This is 95% of the code.
2. Then profile it. Run it, see what’s slow, find the hot path. You will usually discover a counterintuitive but extremely consistent rule: 5% of the code accounts for 95% of the runtime — some inner loop, some serialization step, some matrix multiplication.
3. Hand-optimize that 5% until it hugs the hardware. SIMD, intrinsics, cache-friendly data layouts — whatever it takes. Leave the other 95% alone. Clarity beats cleverness everywhere else.

The result is a deliberately asymmetric shape: cold code is kept clear and flexible; hot code is made fast.

Flip it either way and the system falls apart:

• Write the whole thing in assembly and you get something fast, brittle, and unevolvable.
• Leave the hot path in pure Python and the program is technically correct but processes a hundred records per second. Nobody can use it.

There’s nothing philosophical in any of this — it’s just shape. But the shape is strong: frame at the top, hot spots at the bottom; flexibility where it’s cold, hardware-hugging where it’s hot.

A life has the same shape

Drop the same architecture onto a life and it reads:

Build the framework with reason. Run the daily loop on what you love.

Reason owns the low-frequency, long-term, structural decisions:

• which industry to work in
• which city to live in
• who you marry, who you work with
• where you put your money
• who you want to be in five years

You’ll only make a couple of dozen of these decisions in a lifetime. Each one is heavy. Each one needs a calm, sometimes counterintuitive piece of reasoning. This is the cold-code layer — clear, flexible, explainable. You don’t need to enjoy the process of making the decision — you only need to be sober at the moment of the choice.

Passion — what you actually love — owns the high-frequency, daily, embedded-into-every-hour stuff:

• the work you do when you wake up
• what you eat and who you eat with
• how you train, what you read, how you play
• how you talk to your family, friends, partner

These run every day. If they’re not driven by something you actually care about, they run the way a Python inner loop runs — technically correct, quietly bleeding energy every second.

The cost of misallocation

Run the model in reverse and a lot of “why is this person miserable in a successful-looking life” patterns become legible.

Misallocation 1: forcing reason to drive the hot path.

A lot of people pick a job that looks correct on paper but they don’t actually like, then white-knuckle through it on “I should.” From the systems view this is a hot path running un-compiled high-level code. Reason can issue the instructions, but the CPU executes them slowly, expensively, and with constant overhead. Every day burns extraordinary compute just to produce actions that should have been automatic.

Over a decade, that’s 20,000 hours of work, every hour of it high-friction. What eventually breaks people isn’t usually the difficulty of the job — it’s the cost of the white-knuckling itself.

Misallocation 2: letting emotion drive structural decisions.

The mirror image is just as costly. Moving in with someone the week you meet them. Quitting a job because of one bad standup. Putting your entire savings into a project because you came out of a dinner energized. This is wiring volatile, highly local emotional signals into the heaviest decisions in your life.

Cold code has to be reasoned about in a non-hot state. Structural decisions need you-when-calm, not you-when-fired-up. Emotions still matter as input — they’re often pointing at something true — but they shouldn’t be executed straight through.

Wiring a passion directly into a decision that should have been cold is like soldering an unfiltered power supply onto a motherboard. It might run fine for a while. Then a voltage spike hits and the whole board burns through.

Why “do what you love” is an engineering requirement

Pull “do what you love” out of its romantic packaging and you find an engineering requirement underneath. The reasoning is unglamorous and physical:

1. The hot path has to be supported in hardware. You’re going to execute these actions tens of thousands of times. They have to be supported at the bottom layer. In humans, the bottom layer is emotion.
2. Holding behavior in place with reason, against the emotional layer, costs an enormous amount of energy. Over time you get willpower depletion, emotional flattening, chronic fatigue — basically the CPU exhausting itself emulating instructions the hardware refuses to support.
3. Loved behavior on the hot path compounds. The more you do it, the more you want to do it; the more you want it, the better you get. That’s a positive feedback loop — exactly the structure that makes hot paths in software keep getting faster every release. Cold-code improvements are linear. Hot-code optimization is non-linear.

Put those three together and “do what you love” stops being a personal preference. It becomes something close to a physical fact about how a system can keep running for a long time.

Closing

If the whole model has to compress to one line:

Let reason own your once-a-decade choices. Let what you love own your once-a-day actions.

Hume’s 1739 English, read through a 21st-century compiler, turns out to point at the same advice — do what you love isn’t a luxury, isn’t sentiment. It’s a necessary condition for a system that has to keep running. Cold code is written with the head. Hot code hugs the metal.

Your life is a program with a 70-year runtime. It deserves to be optimized properly.