Skip to content
Published on

Trust the System, Not Yourself — The Secret to Not Making Mistakes

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Opening — I Forgot Again

It was right before a deploy. A feature that ran fine in staging blew up in production. The cause was almost embarrassing: I had not added a single environment variable to the production config. I had remembered it, clearly. "Oh, I need to add that later." That "later" simply never came.

That day I was angry at myself. "Why am I so careless? Next time I will really focus." And a month later, I made nearly the identical mistake. Only the variable was different.

At first I believed more effort would fix it. I stuck on Post-its, set alarms, repeated the item in my head over and over. And still, at the decisive moment, the item slipped out of consciousness. The amount of effort wasn't lacking; trying to patch it with effort was itself the wrong approach.

By the third time, I accepted something important. The problem was not my mental discipline. The problem was that I was working on top of a system that trusted my memory and my willpower. From that day, I adopted a motto.

Do not trust yourself. Trust the system.

This essay is about stopping the self-blame and changing the structure instead. Not abstract resolutions, but concrete checklists, automation, and routines you can actually hold in your hand.

Human Memory and Willpower Are Imperfect

Let me start by admitting an uncomfortable truth: our brains are not reliable storage devices.

The psychologist George Miller, in his 1956 paper "The Magical Number Seven, Plus or Minus Two," argued that the number of chunks a person can consciously juggle at once is around seven. Later research pushed that number down, estimating real working-memory capacity at roughly four items. In other words, the number of things we can hold in mind under a "don't forget this" banner can be counted on one hand.

Willpower behaves similarly. The "ego depletion" hypothesis — the idea that willpower drains like a finite resource — has faced replication debates and should not be swallowed whole, but one thing is clear. When we are tired, hungry, racing a deadline, and juggling three things at once, our judgment is worse than usual. And that is precisely the moment mistakes happen.

What's more, our memory is not merely weak — it actively deceives us. We become certain we did something we didn't, or did twice something we thought we hadn't. Memory is less a recording than a story reconstructed afresh each time. That is exactly why the sentence "I clearly remember, so it's fine" is the most dangerous one of all.

Here is the crucial shift. If we treat a mistake as a flaw of character — "what is wrong with me?" — the only remedy is "try harder." But trying harder is not sustainable. If instead we treat a mistake as a flaw in our environmental design, the remedy becomes "fix the environment." And an environment, once fixed, keeps working on its own.

The Checklist — The Simplest Revolution

No discussion of this topic is complete without Atul Gawande's The Checklist Manifesto (2009). Gawande is a surgeon, a member of one of the most highly trained professional groups in the world. And yet what he discovered was that even brilliant, skilled people cause disasters by skipping simple steps.

In a study conducted with the World Health Organization, introducing a mere nineteen-item checklist into operating rooms meaningfully reduced post-surgical complications and mortality across multiple hospitals. The items were things like "Did you reconfirm the patient's name?" and "Was the antibiotic administered?" — steps so obvious that they are exactly the ones most easily skipped.

The reason checklists are powerful is paradoxical: they distrust the expert. No matter how veteran you are, humans miss things. A checklist exists not because "you are unreliable" but because "humans simply are."

The aviation industry embraced this lesson first. Pilots read aloud and verify fixed checklists before takeoff, before landing, and during emergencies. A captain with tens of thousands of flight hours is no exception. They do not trust their own memory. That is why they are safe.

In software, the principle applies directly. Deploy checklists, code-review checklists, incident runbooks — all are products of the same philosophy.

Let me give one case. A team I once belonged to ran every deploy with one person mentally deriving "what do I need to check this time." When that person's condition was good, all was well; when they were tired, an accident happened. In other words, our stability depended on one person's mental state on a given day. Far too precarious a structure.

We turned that precariousness into a single document. We collected every deploy incident we'd had and translated each into "what should we have checked to prevent this," writing them as check items. It started at seven lines and grew by one each time an incident occurred. Then something remarkable happened: the same kind of incident never happened twice. A mistake we suffered once was pinned to the checklist and could never surprise us again.

This is the checklist's second power. It is not merely a tool to prevent omissions but a memory device that permanently stores what an organization has learned from its mistakes. People leave and memories fade, but a well-maintained checklist compresses all the pain a team has endured and hands it to the next person.

Pre-deploy checklist (example)
[ ] Is the migration script reversible?
[ ] Were new environment variables added to production?
[ ] Was the feature-flag default verified?
[ ] Do monitoring and alerts remain valid after deploy?
[ ] Can the rollback procedure be written in one line?

These five lines would have saved me that day.

Trust the System Rather Than Yourself

"Trust the system" can sound like self-deprecation. It is precisely the opposite. People who trust their systems can spend their energy where it actually matters.

Consider it. Someone who re-derives "what do I need to check at deploy time" in their head every single time wastes that cognitive fuel in the same place repeatedly. Someone whose checklist does that work can spend the same energy on a genuinely hard question, like "will this design still hold up six months from now?"

I call this "outsourcing decisions." Decide well once, and you no longer have to decide again every time.

  • Keep a fixed breakfast so you do not deliberate over food every morning.
  • Adopt a commit-message convention so you do not reinvent the format each time.
  • Keep a meeting-notes template so you do not rethink how to record each meeting.

Hand these small decisions to the system, and your mind gets lighter while your mistakes get fewer. Freedom is not having many options; it is being freed from having to make the unimportant ones.

One balance is worth stating. "Trust the system" does not mean "stop thinking." Systems are for the normal and the repetitive. In exceptional, novel situations, human judgment is still required. A good system handles the repetitive ninety percent automatically so that people can focus on the genuinely hard ten percent.

Why We Resist Systems

Many people nod along this far and still don't use checklists. I was that person for a long time. Why? There are a few psychological resistances.

Pride. "I have to write down something this simple? I can remember that much." Using a checklist feels like admitting you're unreliable. But as we saw, the world's best surgeons and pilots use them. Using a system is not a mark of weakness but a mark of a professional.

Overconfidence. We rate our own memory far higher than it actually is — the "overconfidence bias." The feeling that "I won't forget this time" is almost always wrong. Having forgotten the last ten times, we still believe this time we'll remember.

Immediate cost. Building a system costs time right now. Its reward, meanwhile, arrives as the prevention of a future mistake that never happens. Paying a visible cost for an invisible reward is something humans instinctively dislike.

The way to overcome these resistances is not willpower but experience. Once a system actually saves you a single time, from then on it is relief, not pride, that reaches for the system. So the fastest persuasion is to start with one small thing and taste the effect yourself.

Interestingly, the more comfortable someone is with systems, the less they trust their own head. And paradoxically, that makes them freer and bolder. It's like a driver who trusts the seatbelt going farther. Someone who has handed the fear of falling to the system spends that energy climbing higher. Not clinging anxiously to their own memory, they have the room to face the genuinely hard problems head-on.

Empty Working Memory — Externalize Your Head

David Allen's Getting Things Done (2001) carries this insight: "Your mind is for having ideas, not holding them."

When "I need to do this" floats in your head, that item incurs two costs. First, the risk of forgetting. Second, the cognitive load of clutching it so you do not forget. The Zeigarnik effect — the tendency of unfinished tasks to keep surfacing in consciousness — is exactly this second cost.

The solution is simple: get everything out of your head. Write it in one trusted place, and the brain relaxes — "this is safely recorded over there, I no longer need to hold it."

My practice looks like this.

  • Every task that surfaces goes into one place (an inbox) within five seconds. Sorting comes later.
  • When I'm reading code and think "I should fix this later," I immediately leave a TODO comment or an issue. Never in my head.
  • At day's end, I empty whatever remains in my head into tomorrow's list — so work thoughts do not follow me home.

The key is "one trusted place." If notes scatter everywhere, you stop trusting the system itself, and you fall back on your head. A system only works when it is trusted.

Automation — Work a Human Should Never Do

One level above the checklist sits automation. A checklist helps a human not skip a step; automation removes the human entirely. Where there is no human, there is no human error.

The criterion is simple. Work that is repetitive, rule-bound, and catastrophic when wrong is the top candidate for automation.

  • Nobody worries about code formatting. A formatter handles it on save.
  • Nobody remembers to run lint and tests. Commit hooks and CI enforce them.
  • Nobody types deploy commands by hand. A pipeline runs the same steps the same way every time.

Below is a small example: a hook that blocks a commit outright if tests do not pass.

#!/bin/sh
# .git/hooks/pre-commit
# Reject the commit if tests fail

npm test --silent
if [ $? -ne 0 ]; then
  echo "Tests failed. Aborting commit."
  exit 1
fi

With this hook in place, the sentence "I forgot to run the tests" becomes impossible. The system does not permit it.

Automation has one subtle balance. What you automate becomes invisible, and while it works, even its existence is forgotten. Then one day it quietly breaks, and things can drift for a long while before anyone notices. So good automation comes paired with another device that tells you "is this still running well?" Automation is not build-and-forget but build-and-watch.

The real value of automation is not time saved but consistency. Humans waver with their condition, but a well-built script run a thousand times produces the same result a thousand times. Being trustworthy — that is the essence of automation.

The Ladder of Trust — Systems Have Levels

So far I've discussed checklists, externalization, and automation. These are in fact different rungs of the same ladder. Ordered by increasing strength at preventing mistakes, it looks like this.

The ladder of trust (lower = harder to make the mistake)
1. Remember          -> weakest. Forget and it's over.
2. Write it down     -> won't forget. But you must look.
3. Checklist         -> omissions stand out. But a human must read.
4. Auto reminder     -> the system tells you first.
5. Forced validation -> if conditions aren't met, progress is blocked.
6. Full automation   -> no human touches it at all.

The insight this ladder gives is clear: for the same mistake, you can choose the level of the system that prevents it. For a trivial mistake, a note (level 2) is enough. But for a mistake that is catastrophic once it happens, you must climb to level 5 or 6.

Look again at that day's environment-variable mistake. I stayed at "I'll remember next time" (level 1). So it blew up again. Had I climbed to "the deploy halts if a required variable is missing" (level 5), that mistake could never have recurred.

The crux of judgment is the balance of cost and risk. Climbing higher strengthens prevention but costs more to build. It is reasonable to put frequent, catastrophic mistakes on a high rung and rare, trivial ones on a low rung. Not everything needs level 6 — that is the trap of over-process.

Make It Beautiful — Striking From Near and From Far

Let me make a slightly different argument here. A system should not merely function; it should be beautiful. This is not a matter of taste but of practicality.

Steve Jobs liked to tell a story. When his father built furniture, he finished even the hidden back panels with care. Asked "but nobody sees it," the father replied, "I do." The quality of the unseen parts ultimately makes the quality of the whole.

A good system has two aesthetics.

Beauty seen from afar — Does the overall structure read at a glance? Are the directory layout, module boundaries, and data flow clean? Can a newcomer understand "ah, this is how it works" within thirty seconds?

Beauty seen up close — Is each line clean? Are the variable names honest? Do the comments avoid lying? Are indentation and line breaks consistent?

Why does this relate to mistakes? A messy system hides mistakes. In a well-ordered system, the odd thing stands out. A stain on a clean desk is immediately visible; on a cluttered desk it disappears. Tidiness is not perfectionism — it is a safety mechanism for catching anomalies early.

[Beauty from afar]              [Beauty up close]
+----------------+             one function does one thing
|  clear bounds  |             names say the intent plainly
|  one-way flow  |   +-->      constants instead of magic numbers
|  few deps      |             comments explain "why"
+----------------+             consistent formatting

The time spent making things beautiful is not a cost but an investment. When your future self, or the colleague beside you, rereads that system six months later, the investment returns with interest.

Routines and Templates — Don't Start From Scratch

The system has another face: routines and templates. A routine is a system of time; a template is a system of form.

A routine predefines "when to do what." Review code at the same time each morning; retrospect on the week every Friday afternoon. With a routine, you no longer decide "when shall I do this" each time. The decision is already made.

A template predefines "in what form to do it."

  • Meeting-notes template: agenda, decisions, action items, owner, deadline.
  • Issue template: reproduction steps, expected behavior, actual behavior, environment.
  • Retro template: what went well, what was disappointing, what to try next.

With a template, you never have to recall "which fields was I supposed to fill in." You just fill the blanks. Omission becomes structurally difficult.

I use templates when writing essays too: opening, concept, body, pitfalls, closing. Starting from a blank page is daunting, but blanks just need filling. Removing the friction of starting — that is the hidden power of a template.

Designing the Environment — Make the Right Thing Easy, the Wrong Thing Hard

The deepest form of a system is "changing the environment itself." Instead of using willpower to do the right thing, make the right thing the easiest path so you flow toward it naturally.

The behavioral economists Richard Thaler and Cass Sunstein laid out this idea in Nudge (2008). People usually take the path of least resistance. So if you design the right choice to be the most frictionless path, the right choice happens without spending willpower.

Applied to preventing mistakes, this runs in two directions.

Make the right thing easy. Remove friction from good behaviors you must do often. If you should run tests frequently, make them run with a one-character command or a shortcut. When friction is high, people eventually stop.

Make the wrong thing hard. Add friction to dangerous actions on purpose. Make issuing a command directly against the production database pass through one extra confirmation. When the dangerous path is too smooth, someday you slip.

Two directions of environment design
Right thing -> reduce friction -> naturally done often
Wrong thing -> add friction    -> hard to do by mistake

The key shift is this. Instead of resolving to "be careful" to prevent a mistake, build "an environment where the mistake is hard to make." Willpower is a resource you must summon fresh each time, but an environment, once designed, works automatically every day. Design always beats willpower.

A small example. If you've learned that coding past midnight invites mistakes, the systemic fix isn't "be careful at night" but "automatically lock build-server access at midnight." Don't trust the person; let the environment guard for you.

This principle transfers straight to daily life. To eat less at night, don't resist by willpower — just don't keep snacks in the house. To work out in the morning, lay your gym clothes by the bed the night before. When the environment places the right choice closest to hand, willpower is barely needed. What we cannot control is our future willpower; what we can control is the environment of this present moment. So for our future self, our present self designs the environment.

Beware Over-Process — The System's Trap

Here we must hold a balance. Systems are good, but the moment a system becomes the goal, it turns to poison.

Common traps:

Process for its own sake. A thirty-step checklist nobody reads, meeting notes filled in for form's sake, a rite of passage that passes only to pass. These consume time without granting safety. A checklist is effective only when short and limited to truly risky items. Gawande emphasized it too: a good checklist captures not everything, but the few critical things easily missed.

Systems that are not alive. Reality changes while the document stays frozen. Following a six-month-old procedure to the letter causes a bigger accident. A system needs another system that checks "is this still valid?"

Systems that kill autonomy. Bind everything in rules and people stop thinking. A good system does not turn people into robots; it frees them to focus on more valuable judgments.

Here is one test: "What mistake happens if this process is absent?" If you cannot answer concretely, the process is probably dispensable.

Become Someone Who Builds Systems

Finally, a level up. Beyond someone who follows systems well, become someone who builds them.

If you made the same mistake twice, that is not a willpower problem but the absence of a system. On the third time, instead of getting angry, ask: "What would I have to change to make this mistake structurally impossible?"

  • Dropped an environment variable again? Add validation that halts the deploy if any variable is missing.
  • Got the same question from a colleague a third time? Document the answer and send the link.
  • Doing the same setup by hand every time? Turn it into a script.

This is the real leverage: one effort that prevents countless future mistakes. The difference between a good engineer and a great one is not in making no mistakes. It is in fixing the system so the same mistake never recurs.

And this is not about software alone. If you keep forgetting commitments, build a system called a calendar reminder; if you keep postponing exercise, a system called a fixed time; if you cannot save money, a system called automatic transfer. Instead of enduring by willpower, let the structure endure for you.

Repeatable Process — Replaying One Success Forever

How do you do well next time what you did well once? Rely on memory and it blurs. The answer is to turn it into a repeatable process.

A good process converts "something that went well by luck" into "something that always goes well." You record one success and replay it exactly whenever needed.

I call this "codifying success." When something goes well, I stop in that moment and ask: "Why did this work? What do I need to write down to do it the same way next time?" Then I leave that answer as a procedure.

Turning one success into a process
1. Right after it goes well, while memory is fresh, stop
2. Write down "what, in what order, and why" you did
3. When the same task recurs, follow the procedure
4. When you hit a snag while following it, fix the procedure
5. When the procedure is stable enough, consider automating it

The real power of a repeatable process is "reproducibility." Just as a scientific experiment is trusted because anyone can get the same result with the same procedure, a good process lets the me of six months from now, and a newly joined colleague, do exactly what I did today. It is the moment knowledge trapped in one person's skill becomes the team's asset.

There is a subtlety here. A process is "discovered," not "invented." Sit at a desk and imagine a perfect procedure and it will diverge from reality. The right way is to refine the procedure little by little, at each snag, as you actually do the work. A process is a living document.

A Dialogue Example — From Self-Blame to System

Let me turn the abstract into a concrete scene. Compare two dialogues.

The self-blaming dialogue

Colleague: The deploy broke again because that variable was missing.
Me:        Ah, sorry. I wasn't paying attention.
Colleague: Please be a bit more careful next time.
Me:        Yes, next time I'll really be careful.
(A month later, the same thing repeats)

The conclusion of this dialogue is "be more careful." But care wavers, and so a month later the same thing happens again. The apology was sincere, but the structure didn't change at all.

The dialogue that turns it into a system

Colleague: The deploy broke again because that variable was missing.
Me:        This is the third time. Care alone won't cut it.
Colleague: So what do we do?
Me:        I'll add a script to the pipeline that checks all required
           variables before deploy. If any is missing, the deploy halts.
Colleague: Nice. Then a human won't need to remember.
Me:        Right. From now this mistake is structurally impossible.

The difference between the two dialogues is not attitude but conclusion. The first tries to fix the person; the second fixes the system. The person will forget again, but the system will not.

The key is to aim the arrow at the environment rather than your character. When you say "because this mistake is structurally possible" instead of "because I'm inadequate," real solving finally begins.

Practice — Something You Can Do Today

Enough theory. Let's start small.

  1. Write down your single most frequent mistake. Ideally one you've repeated at least twice recently.
  2. Make a one-line check item to prevent it. It need not be grand.
  3. Put that item where you can see it — not in your head, but in a doc, a template, or automation.
  4. Review in a week. If it works, keep it; if not, discard it.

A system is not finished in one stroke. It begins with a single small check item and grows a little each time you meet a mistake. That process itself is kaizen.

Checklist — Build This Essay Into a System

Finally, here is a checklist that turns this essay into a system.

Trust the System, Not Yourself — Self-check
[ ] Have I made the same mistake twice or more? -> Suspect the system
[ ] Is "don't forget" floating in my head? -> Write it out
[ ] Am I doing repetitive/rule-bound/critical work by hand? -> Automate it
[ ] Do deploy/review/response have checklists?
[ ] Are those checklists short and limited to essentials?
[ ] Is the system clean both from afar and up close?
[ ] Do meetings/issues/retros have templates?
[ ] Is there anywhere process has become the goal?
[ ] Is there another system that audits stale docs?
[ ] Am I a follower of systems, or a builder of them?

Remember: willpower wavers, memory leaks, condition shifts. The only thing that does not change is a well-built system. So today, again — do not trust yourself; trust the system. In the end, that is the most caring thing you can do for yourself.

Closing — The Sturdiest Way to Care for Yourself

This essay reduces, in the end, to one sentence: a mistake is not a problem of character but a problem of design.

This view frees us. Self-blame drains energy and fixes nothing. Seen through the lens of design, however, every mistake becomes a clue for improvement. The moment "what is wrong with me" turns into "what would I change so this doesn't happen," we move from victim to designer.

Of course a system is not a cure-all. Before novel situations, problems that need creativity, and the subtle judgments between people, we ourselves must still step up. The purpose of a system is not to replace us but to carry the repetitive burden so we can pour all our strength into what truly matters.

So "do not trust yourself" is, in truth, "care for yourself." Instead of entrusting yourself daily to wavering willpower, lean on a well-built structure. That is the sturdiest gift you can give your future self. Today, build one small check item, one small automation. The you of six months from now will surely be grateful.

And one more thing. Don't try to build a perfect system in one go. A system, too, is made by people, so at first it is clumsy and full of gaps. That's fine. What matters is starting, then fixing it a line at a time as you meet each mistake. That way the system grows with you, and before long it becomes a colleague far more reliable than you are.

References

Discuss on Twitter • View on GitHub