I’ve been realizing something lately: I don’t remember nearly as much as I think I do. I experiment with a lot of things — internal family video sites, small apps, Ollama endpoints, databases, Docker configs, EC2 instances — and I rarely document everything perfectly. At the time, it all feels obvious. Months later, when I need to redeploy or fix something, I’m staring at configs wondering, “How did I wire this up again?”
It’s not that the concepts are hard. I still understand how MySQL works. I understand port mappings. I understand container networking. What I forget are the small, glue-level details: which port I exposed, how the internal networking was configured, which environment variables were set, how services were allowed to talk to each other, or what subtle flag made something finally work. Those details are what cost hours.
Yesterday I was redeploying an internal family video site — essentially a private YouTube-style setup. I realized I had built something similar before for someone else. When I tried to reconfigure the database and connect services, I couldn’t immediately remember how I’d done it. But once I pulled up the other working system, everything became clear. Not because my memory improved, but because I had something concrete to compare against.
That’s when it hit me: the real power isn’t memory. It’s having two versions of something.
When you only have one system, you’re forced to rely on recall. When you have two — say dev and prod — you can compare. And comparison is far more reliable than recall. You’re not guessing how something was configured; you’re diffing reality. You’re not reconstructing knowledge; you’re inspecting a living reference implementation.
Ideally, you have dev, staging, and prod. But even if you strip it down, having at least dev and prod changes everything. If prod breaks, dev becomes the reference. If dev breaks, prod becomes the reference. Either way, you’re not sitting there trying to remember what you did three months ago.
The interesting part is that this isn’t really about uptime or redundancy in the traditional sense. It’s cognitive redundancy. A second environment becomes executable documentation. It’s better than notes because it’s real. It’s better than comments because it runs. It shows you exactly how services talk to each other, which ports are exposed, how environment variables are structured, and how your networking is actually wired.
I’m starting to think of this as a simple principle: if something matters, build it twice. Not necessarily at massive scale, but in a way that allows you to reference and compare. Two implementations force you to clarify assumptions and expose hidden coupling. They make patterns visible. They reduce the amount of knowledge trapped in your head.
As I get older, I realize time is more expensive than infrastructure. Re-learning something you already solved is costly. Spinning up a second environment is cheap. The difference between the two is often a few dollars a month or a few extra containers, but it can save hours of mental reconstruction later.
The “power of two” isn’t about scale. It’s about cognition. One system requires memory. Two systems allow comparison. And comparison is a superpower.
Going forward, I’m going to be more intentional about always having at least dev and prod. I’m going to treat dev as a template and prod as validation. I’m going to extract configuration into reusable patterns instead of assuming I’ll remember. Most importantly, I’m going to stop trusting memory and start trusting systems.
Because in the end, you don’t need a better brain. You need better mirrors.