Here’s a rewritten version of the article, preserving its core message and storytelling while improving clarity and flow:
—
🖥️ Old-School Deployments and the Journey to Sanity
When I was starting out in software development—back when the internet still felt like the Wild West—I spent two years working on a web-based product that was never released beyond an internal test machine. Our only testers were two colleagues who had to manually tweak their hosts files just to access the site. We weren’t just slow to release—we didn’t release at all.
Even if you’re not an Agile purist, you can see the problem: no real-world feedback, no early user interaction, and a mountain of code waiting to explode when finally deployed. Unsurprisingly, that first deployment to a production web farm was… memorable.
🚨 Deployment Gone Wrong
As a junior developer, I was spared from the initial deployment chaos. But a few months later, my team lead casually asked, “Can you come in Tuesday at 2 a.m. for a deployment?”
I laughed. “Sure thing,” assuming it was a joke.
It wasn’t.
When I strolled into the office at 9 a.m. Tuesday, my team lead and the architect were already there, bleary-eyed and stressed.
“You said you’d be here at 2 a.m.,” he said.
“Oh,” I replied. “I thought you were joking.”
He wasn’t. And the deployment had gone sideways.
Fortunately, I had one advantage over my senior teammates: sleep. My rested brain quickly spotted the issue—a code change related to cookie handling that worked fine on our internal test server but broke everything in production. That discovery probably saved me from a lecture. Years later, it became a funny story shared at my farewell party.
😴 Sleep Deprivation Is a Bug, Not a Feature
No doubt the senior devs would’ve found the issue themselves under better conditions. But they were exhausted, stressed, and unsure if the issue stemmed from code or the manual deployment process: zipped files copied to servers, config files edited by hand, database schemas manually updated—all at 2 a.m.
They were searching for a needle in a haystack they’d built themselves.
If we’d had automated deployments, the haystack wouldn’t exist. We could’ve run a release at 6 a.m., verified it, and gone live with confidence—without risking burnout or errors. And the company would’ve saved time and money.
🚗 Manual Deployments at 2 a.m. Are Dangerous
I eventually did attend many 2 a.m. deployments. The company bought us breakfast and let us leave early—assuming we survived the drive home. But these deployments weren’t just exhausting; they were risky. The checklist was always out of date, and the manual process made it hard to trace issues or roll back safely.
The whole experience was a step back from my previous internship, where I had to write installers to ensure code worked on machines I couldn’t access. With web development, the temptation to “just fix it live” was strong—especially when the full deployment process was painful.
That’s why automation needs to be the only way to deploy. Lock it down.
🧠 Automate or Die Trying
As I grew more senior, I started exploring better ways to deploy. I found talks like “Stop Deploying Like an Idiot” and advice from Octopus Deploy’s founder Paul Stovell: “Your database isn’t in source control? You don’t deserve one. Go use Excel.”
This tough-love approach reminded me of Australia’s famous anti-drunk driving ads: “If you drink and drive, you’re a bloody idiot.” The message? Stop rewarding bad behavior.
Too often, companies reward “hero” developers like Frank—the guy who clings to manual deployments, makes himself indispensable, and resists automation because it gives him power. But Frank isn’t a hero. He’s a risk.
🏗️ Lessons From the Trenches
Manual deployments often reflect outdated hierarchies, but they’re still common. I feel for the developers still stuck in that world. Yes, 2 a.m. deployments can build camaraderie, but they’re also costly and unnecessary.
I saw this firsthand when I toured Adobe’s San Jose office, which featured a “Photoshop floor” with a working Mac running Photoshop 1.0. It was nostalgic—but no one wants to live in the past.
When I finally got the chance to automate deployments, I appreciated every painful manual step I no longer had to do. That’s what drew me to work at Octopus Deploy in 2021.
🐙 What I Learned at Octopus Deploy
At Octopus, the onboarding experience was smooth. But even there, things weren’t perfect—flaky tests, slow builds, and some confusing tooling. That’s normal. No company has a flawless codebase.
Still
