I've recently come across several articles and videos titled "What it's like to be an on-call software developer" or "The harsh truths of being on-call." That framing puzzles me a bit.
Throughout my 20+ year career, being on-call has been an implicit expectation of the role, irrespective of employment contracts, company policies, holidays, or weather conditions.
Because despite what your employment contract says about "standard business hours", as a developer, issues don't wait for you to clock in.
Not officially, not contractually, not morally or ethically, but practically and inevitably, you are always on call.
The Myth of the 9-to-5
Remember when you could clock out at 5 PM and genuinely disconnect from any and all work? Neither do I, because as far back as I can remember, work has never been done.
And this isn't "new" or simply just an artifact of a broken employment system. College and university required all-nighters in the computer labs. High school gave rise to bizarre sleep schedules for most everybody. We've always had a rough relationship with our work and the professional world isn't any different.
Here's what actually happens in the modern dev ecosystem:
A critical bug that surfaces at 10 PM on a Friday, one that's leaking customer data or impacting conversion rates, doesn't wait for Monday morning.
It demands attention regardless of your plans, and often before anyone else has even noticed it.
In my experience, most developers instinctively do the right thing. I've responded to countless off-hours incidents myself, and long before I took on that responsibility, I watched senior developers around me addressing issues around the clock as a matter of course.
The real question is never whether to address it, but when. Does this need to be resolved in the next five minutes, or can it wait a few hours until you're at your desk?
I frequently get pinged on my phone at 3am letting me know that one of the many servers I run is down and can't get up. I think it has something to do with maintenance tasks that run after midnight (of course). And there's only been a handful of times where I've pretended I was dreaming and went back to sleep.
Most of the time, I mechanically reach my hand over to the table next to my bed, and I open up my fast-booting laptop and I reset the server.
The New Social Contract
This article isn't about toxic work culture though. It's about the fundamental nature of software development in 2025. We've built systems so complex and interconnected that the traditional boundaries between "work time" and "personal time" have become artificial constructs.
Consider this: When AWS goes down, do their engineers say "sorry, I'll look at this Monday morning", while the entire north-east quadrant of the country goes down? When your startup's payment processing fails during a product launch, do you tell your CEO it'll have to wait until business hours? Of course not.
We're professionals and that carries a certain responsibility.
The moment you became the person who "knows how the authentication service works" or "understands the deployment pipeline," you became the human single point of failure. Your expertise created an invisible tether to the systems you've built.
And that's not a bad thing. Rising the ranks and climbing the corporate ladder means exactly this. You become the point of contact for a software system and your role is indispensable.
The Uncomfortable Economics
Let's talk money, because that's what makes this really controversial.
Most developers are paid salaries, not hourly wages. Theoretically, this means you're compensated for getting the job done, not for punching a time clock. But here's the kicker: tech salaries are premium precisely because the role includes this implicit around the clock availability.
You're not just paid to write code from 9-5. You're paid to own the problem.
That's why a senior developer makes $150K+ while other professions with similar education requirements top out at $80K. The salary premium isn't just for your technical skills, it's hazard pay for being perpetually on standby.
Companies know this, even if they won't say it explicitly. The unspoken deal is: "We'll pay you well above market rate for other jobs, and in exchange, you'll care about our systems like they're your own."
Again, this isn't something that you're aware of during your first job. But you will pick up on it relatively quickly. Particularly if you are working on a complex system that generates substantial revenue.
Modern Phones Don't Help
Git notifications, Slack alerts, PagerDuty pings, server monitoring dashboards, they're all in your pocket, all the time. You can ignore them for a little while, but you can't forget about them forever. That little red notification badge isn't just an alert, it's a psychological weight.
And the more skilled you become, the deeper you fall into this trap. Junior developers can legitimately say "I don't know how to fix that." and they'll usually be left alone. Senior developers can't. With great power comes great responsibility, and with great responsibility comes great sleep deprivation.
You know that weird bug in the legacy codebase. You understand the quirks of the CI/CD pipeline. You're the one who can diagnose why the cache is behaving strangely. This knowledge makes you valuable, irreplaceable, and perpetually accountable.
When I quit my first programming job, it wasn't long before my old managers rang me up because they couldn't figure out where the morning scheduled tasks were hosted. I was on-call, even when not working there anymore.
But Wait, There's More
Here's where I'll really lose some of you: This isn't a bad thing.
The always-on nature of development has created unprecedented opportunities:
- Rapid iteration cycles that let us ship features in days, not months
- Global collaboration that accelerates innovation
- Remote work flexibility that lets you live anywhere
- High compensation that reflects your true value to the organization
- Continuous learning that keeps the job intellectually stimulating
The traditional 9-to-5 job offers security and boundaries, but it also offers stagnation and limited upside. The always-on developer lifestyle offers chaos and responsibility, but also growth and outsized rewards.
The world can only enjoy the many innovations that we have today, because engineers worldwide stayed the extra hours, had one more cup of coffee and pushed towards that advancement.
Every developer is essentially always on call because we've built a world that depends on software, and software depends on developers. Fighting this reality is like fighting gravity, you'll tire yourself out and change nothing.
The question isn't whether you're always on call (you are), but whether you're okay with that trade-off. Because it is a trade-off: traditional work-life boundaries in exchange for intellectual stimulation, high compensation, global opportunities, and the chance to build things that matter.
Some of us thrive in this environment. Others burn out. Neither response is wrong, they're just different.
But let's stop pretending that development is a 9-to-5 job. It's not, it never was, and it never will be. Once we accept that reality, we can start having honest conversations about compensation, boundaries, sustainability, and what it really means to be a professional software developer in 2025.
Top comments (0)