A few years back I pushed a release to production and broke the whole site for about twenty minutes. The code was fine, and the tests passed. The problem was that our deploy had a specific order to it, and some of that process only lived inside my head.

The deploy process was something like pull the new code, run the migrations, rebuild the assets, clear the cache, then restart the queue workers. That day I pulled the code, rebuilt the assets, and jumped straight to the restart because I was in a hurry and I "knew" the steps. But, as you may have noticed, I accidentally skipped the migrations. So the new code went looking for a database column, and every request that touched that feature threw a 500 error to our users. I spent the next fifteen minutes staring at logs, convinced it was a bug in the code I'd just written, before I realized I'd forgotten a step.

All I'd done was trusted my memory to run a five-step process while I was distracted, and my memory did what memory does, and it forgot something, so I took down a multi-million dollar company during the business day.

Your memory is not a system

When you keep a process in your head, it feels productive. You're fast, you don't have to look anything up, and you get to feel like the person who "just knows how the deploy works." But it's a false sense of productivity because every time you run a process from memory and it works, all you've proven is that you got lucky again.

One of the key things I've learned through years of stepping on rakes is that memory doesn't scale, and it doesn't share. It also degrades when you're tired, rushed, or interrupted, which is essentially my whole life right now. And it's invisible to everyone else, so the day you're on vacation, and someone else has to deploy, all that knowledge is out the door with you.

A better memory won't fix this. Stop asking your memory to do a job that a checklist, a script, or a runbook can do without ever forgetting a step.

Move the recurring stuff out of your head

You don't have to systematize your entire life (but I'm not saying don't). Start with the things you do more than once that hurt when they go wrong. For most of us, that's a short list, and for the teams I've worked with, three items come up repeatedly.

The deploy sequence

That five-step deploy I broke earlier should have been a script (or better yet done with Deployer). Not a fancy pipeline, just a file that runs the steps in the right order so we can't skip one.

#!/usr/bin/env bash
set -euo pipefail

echo "Pulling latest code..."
git pull origin main

echo "Running migrations..."
php artisan migrate --force

echo "Building assets..."
npm run prod

echo "Clearing cache..."
php artisan cache:clear

echo "Restarting workers..."
php artisan queue:restart

echo "Deploy complete."

The first line of code is set -euo pipefail and that tells the script to stop the moment any step fails, so a broken migration halts the deploy instead of letting me sail past it into a restart. The script can't get distracted, and it can't decide to skip a step because it's in a hurry. If you can't script the whole thing yet, write it as a numbered runbook in the repo and check the boxes as you go. Either way, the knowledge lives somewhere that isn't your brain.

The backlog

You're reading through some code, and you spot a bug that isn't part of today's work. You might think, "I'll remember to come back to that," but you won't (@ me, I dare you).

Every "I'll remember" is a promise you're making on behalf of a future version of yourself who is going to be just as busy and tired as current you. Open an issue, or if that's too heavy for a small project, drop it in a "tasks.md" at the root of the repo:

# Cleanup

- make the guest email a button instead of automatic so we can test it
- generate a 100x100 icon from a podcast's Cover Art
- add a link emoji to the episode title

It's not elegant, but it turns a vague sense of "there's stuff I'm forgetting" into a list you can look at. I have a Claude skill that then loops through my "tasks.md" and creates backlog items for them so then the team can prioritize them.

The environment variables you keep re-deriving

When you (or someone on your team) sets up a new machine, you spend an afternoon rediscovering every environment variable the app needs by running it, watching it crash, and reading the error to learn what's missing. It's a process I've seen on lots of teams.

Commit a .env.example with every key the app expects and a comment on the ones that aren't obvious:

DB_HOST=127.0.0.1
DB_DATABASE=myapp
DB_USERNAME=root
DB_PASSWORD=

# Get this from the Stripe dashboard, Developers > API keys
STRIPE_SECRET=

# Redis is required for the queue, not optional
REDIS_HOST=127.0.0.1

Now, setup is copy the file, fill in the blanks, done. The knowledge you dug up once is written down for every future you. The other day I accidentally deleted my ".env" file, and it took me less than a minute to get back up and running (after I realized what I had done).

You can apply this to all kinds of "default" settings files.

B{Where does it live?} B -->|In your head| C[You're rushed or tired] C --> D[A step gets skipped] D --> E[Production fire] B -->|In a system| F[Run the script or checklist] F --> G[Every step runs in order] G --> H[Done, no drama] ``` -->

Pick one thing

Don't try to do everything all at once. That's a great way to do it for a day, get overwhelmed, and rage quit.

Instead, pick ONE thing this week that currently lives only in your memory. Then write it down as a checklist or turn it into a script, put it in the repo, and use it the next time the task comes up.

This way you never have to trust your memory with it again. Do that a few weeks in a row and the pile of stuff you're trying to hold in your head gets smaller every time.