Fear is the only documented emotion in software engineering that improves system reliability when experienced in appropriate quantities, degrades it catastrophically when absent, and produces a distinctive 3 AM facial expression that has been independently observed on every continent where production servers operate.
It is not, as popular culture suggests, the opposite of courage. In software engineering, fear is courage. The developer who is afraid of deploying on Friday is the developer who has deployed on Friday. The developer who is not afraid of deploying on Friday is the developer who has never been paged at 2 AM on a Saturday morning to explain why the checkout flow is returning HTTP 500 to forty thousand customers while the only person who understands the payment service is at a wedding in Crete.
Fear, correctly calibrated, is a monitoring system. It is the biological equivalent of a Grafana dashboard, except it cannot be silenced, snoozed, or ignored because a previous on-call engineer set the alert threshold to “only page me if the building is literally on fire.” Fear pages you for everything. Fear’s alert threshold is set to zero. This is a feature.
Taxonomy of Engineering Fears
The Fear of Complexity
Complexity fears The Lizard.
This is perhaps the most counterintuitive of all engineering fears, because it runs in the wrong direction. One would expect engineers to fear complexity — the sprawling dependency graph, the forty-seven microservices, the configuration file that requires its own configuration file. And they do, in a mild, ambient way, the way one fears rain on a Tuesday.
But complexity itself — the systems, the abstractions, the accumulated layers of indirection — complexity fears the Lizard. The Lizard’s simplicity is existentially threatening to every over-engineered system. A monolith that handles twelve hundred requests at forty-seven milliseconds does not merely outperform the forty-seven-microservice replacement; it invalidates it. It suggests that the last eighteen months of architectural work were not merely suboptimal but unnecessary. This is the deepest fear a complex system can experience: not that it will fail, but that it was never needed.
“I do not frighten anyone. I sit on a rock. The complex systems frighten themselves — I am merely the rock they see when they look down.”
— The Lizard, who has never raised its voice
This is why Gall’s Law induces such visceral resistance. It is not a suggestion. It is a verdict. Every complex system designed from scratch never works. The law does not say “sometimes” or “usually” or “in certain contexts.” It says never. And the fear that Gall’s Law provokes in architects who have just presented a forty-seven-slide deck proposing a ground-up rewrite is the specific fear of a professional who suspects, correctly, that a lizard on a rock understands their system better than they do.
The Fear of Friday
The Friday Deploy is feared not because Friday is technically different from any other day of the week. The servers do not know what day it is. The CI pipeline does not check a calendar. The load balancer does not take weekends off.
Friday is feared because of what follows Friday: two days during which the developer who deployed will be expected to be unavailable, will attempt to be unavailable, and will fail to be unavailable because the deployment is producing errors at a rate that the on-call engineer — who did not write the code, does not understand the code, and is not being paid enough for this — has escalated with a Slack message that reads, simply, “Are you around?”
“Are you around?” is the most feared three-word phrase in software engineering. It has never, in the history of the discipline, preceded good news.
riclib once deployed a streaming markdown renderer on a Friday at 4:47 PM. The deployment worked. The SSE connections were stable. The server stayed up. But the fear lasted until Monday morning, a sixty-three-hour monitoring session conducted via periodic phone checks during meals, conversations, and what was technically supposed to be sleep. The deployment was fine. The developer was not.
The Fear of the Unreadable
Every codebase of sufficient age contains at least one function that nobody understands. It was written by a developer who left in 2019. It has no comments. It has no tests. It has variable names like x2 and tmpFlag and DO_NOT_REMOVE_THIS_FIXES_PROD. It is called from nine places. It works.
The fear of refactoring this function is not irrational. It is the most rational fear in software engineering. The function is a load-bearing wall in a building with no blueprints. The developer who removes it will discover, at 3 AM, which part of the building it was supporting. The answer is always “a part you didn’t know existed.”
“I have no fear of the unreadable function. I wrote the unreadable function. In 488 bytes of 68000 assembly. In 1990. It still runs.”
— The Lizard, unhelpfully
The Fear of the Pager
The pager at 3 AM produces a specific physiological response that has been documented by sleep researchers, cardiologists, and on-call engineers who are all three of these things simultaneously because they cannot sleep, their heart rate is elevated, and they are debugging a connection pool leak in production while their partner asks, from the darkness, “Is it bad?”
It is always bad. If it were not bad, the pager would not have activated. The pager does not page for good news. The pager does not page to say “Your deployment is performing beautifully” or “CPU utilisation is at a healthy 12%” or “The customers are delighted.” The pager pages to say: something is wrong, you are responsible, and you were asleep, which you will not be again for some time.
The fear of the pager is unique among engineering fears because it persists even when the pager is not active. Former on-call engineers report phantom vibrations — the sensation of being paged when no page has occurred, triggered by similar sounds: a phone notification, an alarm clock, a cat knocking something off a shelf. The body remembers. The body does not forgive.
The Fear of Having Broken Production
This fear differs from all other fears in that it is retrospective. The deployment has been made. The change is in production. The dashboard is green. But the developer knows — with a certainty that no monitoring tool can contradict — that something is wrong. Something they missed. Something that will manifest in four hours, or four days, or at the precise moment when the VP of Engineering opens the application to demonstrate it to a potential client.
This fear cannot be resolved by checking the dashboard. The developer checks the dashboard. The dashboard is green. The developer checks again. Still green. The developer checks a third time, because perhaps the dashboard itself is broken and is displaying green when it should be displaying the specific shade of red that means “your career is over.”
The Caffeinated Squirrel does not experience this fear. The Squirrel deploys with the confidence of a creature that has never once checked a dashboard after deployment, has never been paged, and has never been responsible for production stability because the Squirrel’s proposals are rejected by the Lizard before they reach production. The Squirrel fears nothing. This is the problem.
The Healthy Fear
There exists a calibration of fear that experienced engineers recognise but cannot teach. It is the fear that comes from respecting a system you do not fully understand — not the paralysing fear that prevents deployment, but the attentive fear that makes you read the runbook before deploying, write the rollback script before you need it, and test in staging even when you are “pretty sure” it works.
This fear is indistinguishable from competence. The senior engineer who says “Let me check one more thing before we deploy” is not being cautious. The senior engineer is being afraid, productively, in a way that has been refined by years of 3 AM pages, Friday incidents, and the specific look on a product manager’s face when you say “We may need to roll back.”
The Lizard operates entirely within this calibration. The Lizard is not fearless. The Lizard has been running production systems since 1976. The Lizard has seen every failure mode. The Lizard’s apparent calm is not the absence of fear — it is the presence of fear so thoroughly integrated into decision-making that it looks like patience. When the Lizard says “No,” it is not refusing. It is being afraid, on your behalf, because you have not yet learned to be afraid for yourself.
“The Squirrel fears nothing. The Lizard fears everything, quietly. Only one of them has never broken production.”
— riclib, after a 3 AM page that could have been prevented by saying “No” to one proposal
Measured Characteristics
- Rational fears in software engineering: 5 (all documented above)
- Irrational fears in software engineering: 0 (they are all rational, that is the problem)
- Friday deploys per year by fearful engineers: 0-2
- Friday deploys per year by fearless engineers: 52 (the Squirrel deploys every Friday)
- Production incidents caused by fearful engineers: few
- Production incidents caused by fearless engineers: the rest
- Duration of post-deploy anxiety: 63 hours (Friday 4:47 PM to Monday 8:00 AM)
- Phantom pager vibrations per week (former on-call): 3-7
- Times “Are you around?” has preceded good news: 0
- Systems the Lizard fears: all of them, which is why none of them are down
- Systems the Squirrel fears: none of them, which is why this article exists
- The correct amount of fear: more than you think, less than you feel
- Dashboard checks after deployment (first hour): 12-40
- Dashboard checks that changed the outcome: 0
