The Branch That Worked on Your Machine

🧠 Dev Motivation — July 5, 2026

The Branch That Worked on Your Machine

The scenario: 2 PM. You just pushed feature/auth-migration. Locally, everything is pristine — 247 tests pass, linter silent, integration suite green. You tag reviewers and head out for a walk. Come back to a CI notification. Red. Twelve tests failed. Not the ones you touched — payment service, notification service, user preferences. Tests passing since March. You pull onto your second machine. Tests pass. The difference? Your machine has PostgreSQL 16.3, UTC. CI has 16.2, inherited from a Docker image baked three months ago.

Here's the uncomfortable part: it will keep happening. Not because you're careless. "It works on my machine" is not a bug report — it's a coordinate system. You're describing the same problem in a different frame of reference than CI, staging, and production.

The ones who ship reliably aren't the ones who never make this mistake. They're the ones who stopped treating it as a mistake and started treating it as data.

Stop asking: "Why did it pass locally but fail in CI?"
Start asking: "What am I assuming about the environment that the environment doesn't know about?"

Write down every difference. Timezone? PG version? Environment variable in your .env.local that CI doesn't have? Build an ENVIRONMENT_TRAPS.md — every entry is a future production incident you just prevented.

And run your full test suite in a clean environment before you push. A fresh Docker container. A disposable VM. Something that doesn't know you. Something that has no reason to be nice to you.

The branch that works on your machine is just the warmup. The branch that works everywhere is the one that actually ships.

"Your dev machine loves you. It's biased in your favor. Ship code that survives meeting strangers."