Table of contents
Open Table of contents
The creeping expansion of work
Software engineering problems have a seductive quality. There’s always one more edge case to handle, one more optimization to implement, one more bug that seems tantalizingly close to being solved. This makes it easy to rationalize staying late or accepting “just one more meeting” outside normal hours. The work feels meaningful, and the problems are genuinely interesting. But this is precisely what makes the expansion so insidious.
Remote work has amplified this issue. When your office is your spare bedroom, the boundaries between work and life become negotiable in ways they never were when leaving the office meant physically walking out a door. The timezone trap is particularly brutal. A 5:30 PM meeting for a West Coast manager feels reasonable—it’s barely past normal business hours. For someone in the Midwest, that same meeting starts at 8:30 PM, effectively eating into what should be family time.
But here’s what really stings: it’s not just about the hour itself. It’s about the precedent. Once you’ve established that employees must be available at any hour “in service of the product,” the workday stops having meaningful boundaries. Every evening plan becomes tentative. Every family dinner comes with the caveat that you might need to excuse yourself if something urgent comes up. The infrastructure of normal life starts to erode.
The mythology of the passionate developer
The software industry has constructed an elaborate mythology around the idea that true engineers should be willing to sacrifice everything for their craft. We’re told that if we’re not coding in our spare time, building side projects, and thinking about algorithms in the shower, we’re not really serious about our work. This narrative is convenient for employers because it frames exploitation as passion.
But there’s a crucial distinction between being interested in your work and being expected to live for it. I can find software engineering intellectually stimulating without needing to make it the center of my existence. I can care about solving problems and building quality systems without sacrificing my role as a father and husband. These aren’t competing priorities—they’re different aspects of a complete life.
The “passionate developer” mythology also ignores a basic economic reality: passion shouldn’t be a job requirement that subsidizes poor management. When a company uses “we’re passionate about our mission” as justification for extended hours and minimal compensation, they’re essentially asking employees to donate labor in exchange for the privilege of caring about their work. It’s a fundamentally exploitative arrangement dressed up as idealism.
The real math of work-life integration
Let’s do some basic arithmetic. If you’re expected to work until 6 PM and then attend meetings until 8:30 PM or later, you’re left with perhaps 2.5 hours of waking time for everything else in your life. This isn’t hyperbole—it’s the lived reality for many software engineers in demanding roles.
Now consider what happens in a household where one partner is subjected to these expectations. The other person inevitably becomes responsible for all domestic duties, childcare, and household management. It’s not just that you’re working extra hours; it’s that someone else is picking up all the slack to make your extended schedule possible. The cost of your “dedication” is being paid by your family.
The compounding effects are brutal. When every evening is potentially interrupted, you can’t plan meaningful activities with your children. When bedtime routines are constantly disrupted by urgent meetings, kids stop counting on your presence. When your partner has to handle dinner, cleanup, and evening responsibilities alone night after night, resentment builds. What starts as “temporary” overwork has a way of becoming permanent, and the damage to relationships often outlasts the job that caused it.
The sustainable alternative
Protecting your personal time doesn’t make you lazy or uncommitted. It makes you sustainable. Software engineering is a marathon, not a sprint, and people who maintain healthy boundaries tend to produce better work over the long term. They’re less likely to burn out, make critical errors due to fatigue, or leave the industry entirely.
Healthy boundaries in software engineering look surprisingly conventional. They involve working roughly 40 hours per week, being unavailable for non-emergency communications outside business hours, and treating weekends as time for recovery and personal relationships. This isn’t revolutionary—it’s what most professions considered normal until the tech industry decided that digital work somehow transcended human limitations.
The fear, of course, is that setting boundaries will harm your career. But consider the alternative: sacrificing your health, relationships, and personal well-being for a job that may not even exist in six months. The software industry is notorious for layoffs, pivots, and sudden organizational changes. Betting your entire life on any single employer’s approval is a risky proposition.
The courage to say no
Perhaps the hardest part of maintaining boundaries is the initial moment of saying no. Whether it’s declining an after-hours meeting, refusing to work weekends, or simply stating that you’ll address an issue the next business day, there’s always fear about how it will be received. But here’s what I’ve learned: most reasonable managers respect clear boundaries more than they respect boundaryless availability.
The key is to be professional but firm. You can care about your work without being available 24/7. You can be committed to quality without sacrificing your family life. You can be interested in solving problems without making work the only interesting thing in your life.
When I told my former employer that I could only work 9 AM to 5 PM on weekdays as a contractor, it wasn’t defiance—it was clarity. I was stating the terms under which I could do good work without compromising the other important aspects of my life. Some organizations will reject those terms, and that tells you everything you need to know about their priorities.
A sustainable future
The always-on culture in software engineering is ultimately self-defeating. It burns through talented people, creates instability in teams, and produces lower-quality work than sustainable practices would yield. Organizations that figure this out will have a competitive advantage in attracting and retaining good engineers.
But change has to start with individuals. Every time someone accepts an 8:30 PM recurring meeting without pushback, they’re normalizing that expectation for everyone else. Every time someone works through a weekend “just this once,” they’re setting a precedent that weekend work is acceptable. The culture shifts when enough people decide that their time and families are worth protecting.
Engineering leaders have a particular responsibility here. The decisions you make about meeting times, response expectations, and after-hours availability ripple through your entire organization. Modeling healthy boundaries isn’t just good for you—it’s good for everyone who works for you.
Life is shorter than we think. The time we spend with our families, the memories we make with our children, the relationships we nurture—these things matter in ways that no software project ever will. Being a good engineer and being a good human aren’t competing goals. They’re complementary aspects of a life well-lived.
The hidden cost of always-on culture isn’t just the hours it consumes. It’s the life it prevents you from living. And that cost is too high, no matter how interesting the problems or how passionate the mission. The courage to protect your boundaries isn’t just about you—it’s about creating space for the person you want to be, both at work and at home.