The “always on” identity is not a feature of good engineering. It is a symptom of bad systems, bad documentation and an industry that mistook burnout for dedication.
Someone says it in every team. A senior developer says it during onboarding. A client says it when they hand over the support contract. A founder says it in a job description dressed up as a perk.
“Being a software engineer, there is no 9-to-5.”
And most of us nod. We have been trained to nod. Somewhere between our first production incident at 11pm and our third consecutive weekend deployment, we absorbed the idea that this is simply what the job is. That availability is professionalism. That boundaries are laziness wearing a different shirt.
I disagree. And I want to be specific about what I am disagreeing with.
The Statement Is Not Wrong. The Conclusion People Draw From It Is.
There is a version of “no 9-to-5” that is true. Software does not break on a schedule. A payment gateway going down at 2am on a Saturday does not wait for Monday. A memory leak that only manifests under sustained production load does not check your calendar. If you own a system, there will be moments outside business hours where you need to respond.
That is not what the statement is really saying most of the time.
What the statement is usually doing is normalising a state of permanent availability as an identity rather than as an exception. It is saying that the expectation of your attention, outside contracted hours, with no additional compensation, is simply the nature of the work. It is saying that if you push back on that expectation, you are not a real engineer.
That is the part I disagree with.
What “Always On” Actually Looks Like
I have taken calls at 11pm because a queue worker died and jobs were silently failing. I have SSH’d into a server from a parking lot because a deployment left the application in a broken state. I have debugged a production issue on my phone while waiting for a flight.
None of that felt like passion at the time. It felt like a system that was not resilient enough, a deployment process that had no rollback plan and a monitoring setup that only told me something was wrong after a user reported it.
The incident was not inevitable. The lack of preparation was.
Every emergency I have responded to outside working hours falls into one of two categories. Either it was genuinely unpredictable and required a response, or it was predictable and we had not built the systems to handle it without me being physically present. The first category is rare. The second category is what most “no 9-to-5” moments are actually made of.
The Industry Romanticised the Wrong Thing
There is a long tradition in software of treating overwork as proof of seriousness. The developer who stays until midnight is dedicated. The one who leaves at six has no passion. The startup that expects sixty-hour weeks is building something important. The company with strict working hours is a place where ambition goes to die.
This framing has been challenged consistently by research. A 2014 study by John Pencavel of Stanford University, published as IZA Discussion Paper (No. 8129), found that the relationship between working hours and output is nonlinear. Below 49 hours per week, output scales proportionally with hours. Above 49 hours, output continues to rise but at a sharply decreasing rate. By around 55 to 56 hours, the gains become negligible. The study found that output at 70 hours was roughly the same as output at 56 hours.
You are not more productive. You are more present, which is not the same thing.
The romanticisation of always-on culture is not a feature of good engineering culture. It is a feature of industries where input (hours) is mistaken for output (working software). Software engineering, at its most functional, should be measured by what ships and what stays up. Not by who answered Slack at midnight.
On-Call Is Legitimate. Permanent Availability Is Not.
There is an important distinction to make here. Structured on-call rotation is a legitimate part of operating production systems. If your team runs services that need to stay up, someone needs to be reachable when they fall over. That is a reasonable professional expectation with defined parameters: specific hours, rotation between team members, compensation for the burden.
What is not legitimate is the informal, uncompensated, undefined version of on-call that most developers actually experience. Where you are expected to respond to a client message at 9pm because they know you will see it. Where you are expected to “quickly check” something over the weekend because it will only take five minutes. Where the system has no runbook, no monitoring and no backup contact because the assumption is that you will always be available.
The difference between the two is structure. One is a defined professional arrangement. The other is an indefinite personal obligation wearing a professional costume.
The Engineering Answer to Always-On Culture
Here is the part that makes this an engineering problem rather than just a culture problem.
Most unplanned out-of-hours incidents are preventable through work done during hours. Monitoring that alerts before users notice, not after. Deployment pipelines with automated rollback. Runbooks that let someone else handle common failure modes. Queue workers that restart automatically. Health checks that catch degradation early.
If your system requires your personal presence to survive a weekend, that is not a 24/7 operation. It is a fragile system with a single point of failure who happens to also be the developer.
I have spent more time than I want to admit building those kinds of systems early in my career. Not because I was careless, but because I was fast. Writing the runbook felt slower than just knowing the answer. Setting up proper alerting felt like overhead when I could just check the logs manually. Documentation felt like admin when I could just remember.
The cost of those shortcuts is not paid when you write them. It is paid at 11pm on a Friday when you are the only person who knows which environment variable is wrong and why.
The Honest Conversation About Boundaries
Pushing back on always-on culture is not the same as being unavailable when something is genuinely urgent. Those are different things.
What it looks like in practice: define what constitutes an emergency before an emergency happens. A server that is completely down is an emergency. A client who wants a feature discussed is not. A payment failure affecting active users is an emergency. A report that needs to be pulled by Monday morning is not. Write those definitions down. Share them with clients at the start of the engagement, not at the moment you need to enforce them.
Most clients who expect unlimited availability have never been told otherwise. They are not malicious. They are operating on the assumption that your availability is unlimited because nothing has ever indicated that it is not.
That is a communication problem before it is a boundary problem.
What I Actually Believe
I believe software engineering involves moments of unpredictability that fall outside business hours. I accept that as a reality of the work.
I do not believe those moments should be the baseline expectation.
I do not believe availability at midnight is a measure of professional seriousness.
I do not believe that a developer who keeps structured hours is less dedicated than one who answers messages at all hours.
In my experience the opposite is more often true. Developers with clear boundaries tend to work more sustainably, document more thoroughly and build more resilient systems. Because they know they will not always be there to patch things manually.
The best engineering I have seen is boring at 2am. Not because nothing goes wrong. Because when something goes wrong, there is a system to handle it and a process to follow that does not require a specific person to be awake.
That is what good engineering looks like. Not a developer who is always available. A system that rarely needs them to be.
“But What About Night Deployments?”
This is the most common pushback. And it deserves a direct answer rather than a dismissal.
Night deployments exist for a reason. Most teams that deploy after midnight are doing it because they are afraid of what happens if something breaks during peak hours. The logic is: fewer users active at 2am means fewer people affected if the deployment goes wrong. That logic is not irrational. It is a risk management decision.
But notice what it is actually saying. It is saying: we do not trust our deployment process enough to run it during the day. We need the safety net of low traffic in case we have to scramble.
That is not a scheduling problem. That is a deployment maturity problem.
Zero-downtime deployment strategies exist specifically to remove this fear. Blue-green deployment maintains two identical production environments and switches traffic atomically once the new version is validated. Canary deployment releases to a small subset of users first and watches for errors before rolling out further. Rolling deployment updates servers one at a time while the rest continue serving traffic. All three of these strategies make the deployment reversible at any point and limit the blast radius of a bad release.
When those patterns are in place, there is no meaningful difference between deploying at 2pm and deploying at 2am. The risk profile is the same. The process is the same. The person executing it is more awake at 2pm.
I will be honest here: not every system or team is at the maturity level where daytime deployment feels safe. Legacy systems with no rollback path, complex database migrations with no backward-compatible strategy or clients who explicitly require a maintenance window are real constraints. I have worked in all three situations. The night deployment was sometimes the right call given the circumstances.
But “the right call given the circumstances” is different from “the nature of the job.” Circumstances can be improved. Deployment pipelines can be automated. Rollback can be built in. Database migrations can be written to be backward-compatible. These are engineering problems with engineering solutions. They are not permanent features of what it means to be a software developer.
On late-night bug fixes: The question to ask is whether the bug is actually causing harm right now. A bug discovered at 10pm that affects zero users until the next morning is not a 10pm problem. It is a 9am problem with a head start. Document it, set a reminder, fix it during hours. The urgency is real only if users are actively affected. If they are not, the urgency is anxiety wearing the costume of professionalism.
This is personal opinion, not a universal rule. There are systems where any bug at any hour requires immediate attention: financial transaction processing, emergency services infrastructure, healthcare systems. If you work on those systems, you already know this and you have structured on-call arrangements to match. For the majority of applications, the 10pm bug can wait until morning without consequence.
On timezone differences: This is the most legitimate version of the argument. If your client or your users are in a different timezone, their 9am is your 10pm. This is a real structural challenge, not a false emergency.
The answer is not unlimited availability. It is defined async response windows agreed in writing before the engagement starts. “I respond to non-critical messages within one business day. For production incidents, the response time is two hours.” That is a professional arrangement. It sets expectations. It is not a boundary that needs justification. It is a service level that both parties have agreed to.
Most developers in this situation have never written that agreement down. They have just been available. And because they have been available, the expectation has set itself.
But no, it does not have to be the identity. The developer who never disconnects is not an example to follow. They are a warning about what happens when systems are built around availability instead of resilience.
Build better systems. Then go home.
