Prologue

A bug report from the inside.

Some books open with a quote from a dead philosopher. This one opens with a confession.

I am writing this from a position of considerable moral authority on the subject of anxiety, by which I mean that I have suffered from it for so long that we are now, in most reasonable jurisdictions, common-law married.

Let me get the autobiography out of the way quickly, because nobody picks up a book called The Mathematics of Anxiety hoping for a memoir, and I respect that.

I had a difficult childhood. The details would take a chapter to tell properly, and they will get one later, where they have to earn their keep by illustrating a theorem rather than just lying around looking sad. For now, the only fact you need is that I arrived at the age of eighteen with the standard equipment of a difficult childhood, namely, a nervous system that flinched at sudden noises, and at most ordinary noises, and occasionally at no noises at all.

I also had foster parents, of the optional rather than mandatory kind. They had agreed to fund my college education on the not unreasonable theory that I would do well in college. I, in turn, had agreed to do well in college. One of us kept that bargain. It was not me.

After my first year, having achieved grades that could best be described as a confident downward trajectory, I came home to the news that my sponsorship was being discontinued. There was a conversation. There was a suitcase. There was a door that closed behind me with the soft mechanical certainty of a well-engineered bug, the kind that is reproducible on every operating system.

I was, technically and inconveniently, homeless.

This is the part of the story where, in a different book, the protagonist would discover Jesus, or jazz, or a wise old mentor in a coffee shop. I discovered the C programming language. Specifically, I discovered that I could read it. Most of my classmates looked at C and saw punctuation. I looked at C and saw prose. I am still not entirely sure why. Some people have perfect pitch. I have, apparently, perfect pointer arithmetic.

This skill, modest as it sounds, turned out to be the load-bearing column of the next several years of my life. I got a job at a small computer institute in a small town doing two things at once. In the mornings, I taught beginners how to write FOR loops without setting their machines on fire. In the afternoons, I worked as a lab assistant, which is a job title that means "the person who fixes whatever just broke, while the actual instructor pretends to know what is happening."

The pay was, let us say, character building. I lived on rice, on library books, and on the strange exhilaration of being an eighteen year old in unsupervised charge of an entire room full of computers after hours.

And then, one evening, I had the kind of small thought that quietly resizes a life.

I looked around. I really looked. There were perhaps twenty machines in that lab. There was a wall of textbooks behind me, the institute's modest library, mostly donated, mostly unread. Somewhere in another town, in another life, a kid my age would be saving for months to use a computer for an hour. Another kid would be borrowing one textbook from a public library for two weeks at a stretch. And here I was, broke, mildly underfed, sleeping on a foldout cot in the back office, and surrounded by every tool I would ever need to teach myself anything in the world.

I had, in a sense that almost nobody at eighteen ever has, all the time in the world. All the computers in the world. All the books in the world.

This is the closest I have come to a religious experience, and I do not say that lightly. I had spent twelve years of school being told I was bad at mathematics. I had spent one year of college proving them right. And now, sitting in a half-lit lab at nine in the evening, I picked up a textbook on calculus, opened it to the first chapter, and started over. By myself. Slowly. Hands genuinely shaking, because I was certain that I would discover, on page eleven, that everyone had been correct about me all along.

They had not been. I cannot stress this enough. They had not been. Not because I was secretly brilliant, but because mathematics, it turned out, is one of the easiest things in the world to learn when nobody is yelling at you to learn it faster.

For the next several years I did this every night. Calculus, then linear algebra, then probability, then physics, then more computer science than was strictly healthy, then a little philosophy when nobody was looking. The childhood trauma stayed exactly where it was, on the cot beside me, occasionally tapping me on the shoulder to remind me that none of this was going to make it go away.

It did not, in fact, make it go away. The trauma followed me into my twenties, into my career, and most of all into my relationships, where it did the kind of damage that you can only do to someone who has agreed to love you. I tried therapy. Therapy is a wonderful invention. It just did not work on me, the way some antibiotics fail on some bacteria, with no particular grudge on either side.

So one evening, a much older version of the kid in the lab sat down at a desk, opened a fresh notebook, and did the only thing he had ever been any good at. He started debugging.

Not the trauma. The trauma is the input. You cannot debug the input. What you can debug is the function the input passes through, which is to say, the algorithm your brain runs when life hands it something difficult.

I started writing equations for things that are not normally written as equations. I started thinking of moods as time series, of rumination as recursion, of rumination without a base case as the specific kind of recursion that crashes the program. I started noticing that everything therapists had been trying to tell me, in the soft language of therapy, had a precise twin in the harder language of mathematics, and that for some kinds of brains, the harder language is the easier language.

This book is the result. It is, I hope, scientifically and mathematically accurate, in the sense that every equation in it can be checked, every algorithm can be run, and every Python snippet will execute without setting your laptop on fire. It is also, I hope, funny, because the alternative is unbearable.

If you are anxious, this book is for you. If you are not anxious, but love someone who is, this book is for you. If you are neither, and you simply like mathematics, this book is for you, but you should know that it occasionally cries.

We start in the next chapter, with the brain, which I will be treating throughout as a piece of legacy code with deeply opinionated maintainers and absolutely no documentation. Bring coffee.

Introduction

What this book is, and what it has been told not to be.

A few honest words about what you have just bought.

This is not a self-help book. I have read self-help books. Self-help books say things like "you are enough" and "honor your journey," and other phrases that sound reassuring until you try to put them into practice, at which point they evaporate, leaving a faint aroma of essential oils and the distinct suspicion that you have been gently scammed.

This is a book about anxiety, written by someone who has it, for people who have it, using the only language that has ever made anxiety sit still long enough for me to look at it, which is mathematics.

I should explain what I mean by that, because it sounds either pretentious or insane. Possibly both.

The brain is a machine. I do not mean this metaphorically and I do not mean it dismissively. I mean it in the careful, specific sense that the brain is a physical object that takes inputs, performs operations on them, and produces outputs, and that this process, while staggeringly complicated, is not magic. It runs algorithms. It has memory. It has a clock. It overheats. It deadlocks. It occasionally produces results that are not just wrong, but interestingly wrong, in patterns that, if you squint, look an awful lot like the bugs you would see in any other piece of badly maintained software.

Anxiety is one of those bugs. So is depression. So is rumination, panic, perfectionism, the specific midnight conviction that you have ruined your life, and the related conviction, arriving promptly at three in the morning, that you are about to ruin it again.

This book takes a single position, which it will defend across roughly three hundred pages. The position is this: if you have a brain that thinks in code and equations, and you have a problem that lives in your brain, then code and equations are not optional tools. They are the home field advantage.

What we will do, chapter by chapter, is take a real piece of mathematics, computer science, or physics, treat it with the rigor it deserves, and then use it as a lens for one specific feature of the anxious mind. We will derive an equation for why chasing happiness makes happiness retreat. We will write Python that demonstrates why some kinds of worry are formally undecidable. We will look at why your worst day is almost certainly not a sample from a population of worst days, but a fluctuation in a noisy distribution. And we will look at this in enough detail that you can compute, on the back of a napkin, how likely it is that tomorrow will, in fact, be better.

I want to be clear about three things before we start.

First. The mathematics is real. Every formula, every algorithm, every piece of code in this book has been written so that a humorless professor could read it without flinching, and a humorless engineer could run it without complaining. If you are math curious but rusty, there is an appendix at the back specifically for you, written without judgment, although possibly with one or two jokes.

Second. The jokes are also real. By which I mean, they are not decoration. They are doing structural work. Anxiety is a condition that takes itself extremely seriously, in part because it has convinced you that the seriousness is the only thing keeping you alive. Humor, properly applied, is one of the few solvents that dissolves this. Every chapter in this book is allowed to laugh at the author, the author's anxiety, the author's worldview, and occasionally at the reader, with love.

Third. I am not your therapist. I am not anyone's therapist. If you are in crisis, please close this book, ring an actual professional, and come back to us when the urgent thing is no longer urgent. This book will still be here. The mathematics will still be true. We will be, as ever, in no particular hurry.

If you are still here, here is the plan.

Part one is short and brutal. We diagnose. We open the hood. We look honestly at what kind of machine the brain is, what kinds of bugs it ships with, and why mathematics, of all the unlikely candidates, turns out to be the right toolkit for the job.

Part two is the bulk of the book. It is the toolkit itself. Fourteen or so chapters, each pairing one rigorous concept to one specific feature of the anxious mind. You can read these in order, or out of order, or in the bathtub, or while pretending to listen to your in-laws. They build on each other gently, but not strictly. Skip with permission.

Part three is where we get practical. We take everything we have built in the toolkit and use it to construct actual, runnable strategies for the anxious life. Not affirmations. Not breathing exercises copied out of someone's yoga book. Algorithms, with inputs and outputs and edge cases, the way a respectable engineer would design them.

The epilogue is short. It is about the only mathematical idea I have ever found that is also, somehow, a moral one. We will get there.

A final note. Throughout the book, I will tell you small pieces of my own story, not because my story is particularly remarkable, but because the equations have to belong to someone, and they might as well belong to me. I will not be portraying myself as a victim, because I do not feel like one, and because the moment a book about anxiety starts feeling sorry for itself, the reader, with excellent instincts, walks away. So when the autobiography appears, please understand that it is on the page in the same spirit as everything else, which is to say, to be useful, and to be laughed at.

Alright. Coffee. Page one. Let us begin.

Chapter one

The brain ships without documentation.

It is a Tuesday, three in the afternoon, and a tiger has just walked into my office.

There is no tiger. I work from home. There is, instead, an email. The email is from a person I respect, the subject line is the single word "thoughts?" with a question mark performing all of the structural labor, and the email itself contains a paragraph I cannot bring myself to read for another forty minutes.

While I am not reading the paragraph, my body is doing the following things. My heart rate has risen by approximately twenty beats per minute, on the theory that I might need to outrun the email. My pupils have dilated, on the theory that the email might be hiding in low light. My digestive system has been politely deprioritized, on the theory that there is no point digesting lunch if the email is about to eat me. And my prefrontal cortex, which is the part of my brain responsible for understanding things like emails, has been administratively suspended, on the theory that subtle reasoning is unhelpful in a knife fight.

A tiger has not walked into my office.

A tiger has never walked into my office.

A tiger has not walked into anyone's office in the entire history of office work.

And yet, here I am, with a body that is, on every relevant biochemical axis, ready for the tiger.

This is not a personal failing. This is a software bug.

If we wrote out what my nervous system actually did in those forty minutes, the resulting Python would look something like this. The code is small enough to fit on the page, which is itself a kind of indignity.

def brain_threat_response(stimulus):
    """
    Threat detection subsystem.
    Last meaningful update: ~200,000 BCE.
    Maintainer: long since departed.
    Tests: see intuition.py.

    Known issue: returns 'leopard' for many inputs
    that are not, in fact, leopards.
    Status: will not fix; behavior is load-bearing.
    """
    SAVANNA_THREATS = {
        'rustling in tall grass',
        'shadow overhead',
        'unfamiliar face',
        'separation from the group',
    }

    if stimulus in SAVANNA_THREATS:
        return 'leopard'

    # Modern stimuli are not in the lookup table.
    # The system defaults to the most familiar response.
    return 'leopard'


# Sample calls:
brain_threat_response('rustling in tall grass')
# -> 'leopard'

brain_threat_response('one-word email from manager')
# -> 'leopard'

brain_threat_response('a slack message that says "got a sec?"')
# -> 'leopard'

brain_threat_response('your daughter is twenty minutes late')
# -> 'leopard'

brain_threat_response('an actual leopard')
# -> 'leopard'

You will notice that the function is, in some technical sense, working perfectly. It does not crash. It returns a value for every input. It does this with the cheerful confidence of code that has been deployed in production for two hundred thousand years and has never been written up in a postmortem.

You will also notice that it is, in every sense that matters, completely useless.

Software engineers have a phrase for the category of bug I have just demonstrated. They call it legacy code.

Legacy code is software written long ago, by people who are no longer at the company, for purposes that are no longer documented, on assumptions that are no longer true. It runs. It runs because the original engineers were not idiots, and the code, in its original context, did its job well. It is just that the context has changed in the intervening decades, and nobody has had the time, or the budget, or the courage, to rewrite it.

Every large company on Earth has legacy code. It quietly runs the bank. It quietly runs the airline. It quietly runs the nuclear reactor. There is, somewhere in a basement in Wyoming, a piece of FORTRAN written in 1971 that calculates the trajectory of a missile, and there is exactly one human being on the planet who fully understands it, and he is seventy-eight, and he charges a thousand dollars an hour to take phone calls, and the United States Air Force pays it without complaint.

Your brain is also legacy code.

It was originally written for a different operating environment. The original engineering team had specific use cases in mind, and those use cases included things like noticing leopards in the long grass, remembering which berries had killed your cousin, and forming small social alliances against larger and stronger enemies. The team did beautiful work. Within those use cases, the resulting machine is one of the most elegant pieces of engineering in the known universe.

The trouble is that the use cases have changed.

Your operating environment is no longer the savanna. It is a brightly lit room with an internet connection, and you spend most of your waking hours in interactions that the original engineers did not, could not, anticipate. You receive electronic messages from people you have never met. You read about disasters happening on continents you will never visit. You compare yourself, daily, to highlight reels from the lives of strangers. You sit in a chair for nine hours so that you can pay for a different chair to sit in for the other fifteen.

None of this is what the brain was built for.

But the brain, being legacy code, does not know this. It runs the same routines it has always run. When it sees an electronic message from a person it respects, with a one word subject line, it consults its threat detection subsystem. The threat detection subsystem looks up "uncertain communication from a member of the in-group" in its lookup table. The lookup table, which was last updated approximately two hundred thousand years ago, returns the result potentially leopard. The brain dutifully takes action.

This is the bug. This is the entire bug.

Software engineers have a small list of properties that distinguish legacy code from ordinary code. I want to walk through them, because the brain checks every box on the list, and the comedy of the resulting picture is, I think, half the consolation.

Property one. Legacy code is written by people who are no longer there.

The original engineering team for the human brain was, depending on where you start counting, somewhere between four hundred million and three and a half billion years long. None of them are taking calls. The architectural decisions made in the Cambrian explosion are still in the codebase. The decision to have a vertebra is still in the codebase. The decision to be afraid of snakes is still in the codebase. There is no senior engineer to consult. The git log goes back further than written language.

You, the current owner of this software, are doing maintenance on a project whose original specification was lost five hundred million years ago, possibly to a rock.

Property two. Legacy code optimizes for an environment that has changed.

The brain is exquisitely well tuned for the late Pleistocene. It is a survival manual for a small group of social omnivores living in conditions of mild scarcity, occasional violence, and frequent uncertainty about whether the dark shape in the bushes is an antelope or something that eats antelopes. It is, in this domain, world class.

In your domain, which involves performance reviews and group chats, the optimization is less helpful. The dark shape in the bushes is now your manager's silence on Slack.

Property three. Legacy code has no comments.

When a programmer writes a piece of code, professional courtesy dictates that they leave behind a few sentences explaining what the code does and, more importantly, why. These sentences are called comments. They are how the next programmer understands what they are looking at.

The brain has zero comments.

The brain does many things and explains none of them. It produces emotions whose origin you cannot trace. It triggers memories you did not request. It assigns terror to envelopes and mild satisfaction to the closing tab on a browser. It does not say why. It just does it. If you ask the brain why it just did the thing it did, the brain produces a confident sounding paragraph called a rationalization, which is technically a lie, but a very smooth one, and which has roughly the same relationship to the actual cause of the behavior as the screensaver has to the operating system.

This is, by the way, well established in psychology. There is a long tradition of experiments in which subjects are made to do something for reason A, asked why they did it, and confidently report reason B. The subjects are not lying. They are reading their own behavior off the screen and inferring the cause. They are guessing, in the same way you would guess at someone else's reasoning. They simply happen to be guessing about themselves.

Property four. Legacy code has tests, and the tests test the wrong thing.

In well written software, there are automated tests that check whether the code is doing the right thing. In legacy code, there are also tests, but they have drifted. They no longer test what the code was supposed to do. They test what the code is currently doing, regardless of whether the current behavior is correct. If you fix a bug, the tests fail. The tests fail because the bug was load-bearing. The tests are now a monument to the bug.

Your brain has tests like this. They are called intuitions. Some of your intuitions are excellent. Some of them were calibrated by a six year old version of you in a household that no longer exists, against threats that have all moved out, and they have never been retrained. When you do something healthy, like say no to a request that would have ruined your week, those intuitions fail loudly. They throw an alarm. The alarm reads danger. The danger, in fact, is gone. The alarm has not been told.

Property five. Legacy code has magic numbers.

A magic number is a constant in the code with no explanation attached. Somewhere in the source, there is a line that says if x > 47 then halt. Why 47? Nobody knows. The engineer who put it there is on a beach in Portugal. The system has been running on 47 for eleven years. If you change it to 46, the building will burn down, although nobody can tell you why.

Your brain has many magic numbers. The amount of attention from a particular person that feels right. The level of output you feel guilty for falling below. The exact arrangement of objects on your desk that feels permissible to leave. None of these constants were derived rationally. They were tuned. They were tuned by experiences you cannot now identify, in childhoods you cannot fully remember, by the small unconscious feedback loops that decided what was safe and what was not. The numbers are still there. They are still being read by your runtime. You are still afraid to change them.

Property six, and this is the worst one. Everybody is afraid to touch the code.

In every software company on Earth, there is a piece of code that everyone agrees is bad and that nobody is allowed to fix. Fixing it is too risky. Other parts of the system depend on its current behavior, including its current bugs. The cost of breaking it is too high. It sits there, generation after generation of engineers, and accumulates a kind of mythology. People speak of it in lowered voices.

Your anxiety is exactly this kind of code.

You know it is buggy. You have known it is buggy for years. You have wanted to fix it for years. But every time you have tried, something else has broken. You stopped being afraid of the elevator and started being afraid of crowds. You stopped being afraid of crowds and started being afraid of going to bed. The anxiety, you have learned, is structural. It is holding things up. You are not sure which things. You are not sure if you can take it out without bringing the whole building down.

This is, I want to say very clearly, an entirely reasonable thing to think. The bug is real. The buttressing is also real. But the building is not, in fact, holding itself up entirely on the strength of one bad function. There is a way in.

The reason I am laying all of this out, on the first chapter of a book about anxiety, is not so that we can spend the next three hundred pages enjoying the metaphor. It is so that we can do something with it.

If your anxiety is a piece of legacy code, then four very useful things follow.

First, it is not your fault. You did not write it. You inherited it. Some of it was written by your mother. Some of it was written by your school. Some of it was written by a stretch of the Pleistocene. None of it was written by you. The fact that you cannot read it does not mean you are bad at brains. It means there are no comments. There were never going to be comments.

Second, it can be debugged. Legacy code is not magic. It is just code. Difficult code, fragile code, code that nobody wants to touch, but code. Which means the techniques that work on legacy code, which is to say careful instrumentation, small changes, lots of tests, and an attitude of patience with the original engineers, will also work here.

Third, you do not have to rewrite the whole thing. This is the relief that I would like, if I could, to deliver directly into your bloodstream. You are not required to scrap your entire personality and start over. You are required, at most, to refactor a small number of specific functions. The rest of the code can stay. Some of it is, in fact, excellent. The function that loves your friends is well written. The function that finds octopuses interesting is well written. The function that makes you cry at the end of films you did not even like is, somehow, a masterpiece.

Fourth, and this is the entire promise of this book, the tools for doing this work already exist. They are the tools we use on every other complicated system. They are calculus. They are linear algebra. They are probability theory. They are the algorithms we teach in undergraduate computer science. They are, in fact, the most thoroughly battle tested set of tools the human species has ever produced for thinking carefully about complicated machines.

The next chapter is a short and unflattering autobiography, because I owe you the credentials. After that, we get to work.

Bring a notebook. The brain ships without documentation. We are about to start writing some.