5:00 PM. Laptop closed. Slack closed. Workday over. Except my brain didn't get the memo.
I'm making dinner, and I'm still half-thinking about a function I left half-refactored. I'm lying in bed, and a bug I never solved wanders back into my head uninvited. Saturday morning arrives with zero meetings, zero tickets, completely open, and somehow by 11 AM I'm three hours deep into my side project again, treating my only unscheduled day like it also needed a sprint plan.
Technically, I'm not working.
I'm still at work. It just moved from my laptop into my head, and it didn't ask permission first.
I think a lot of developers know exactly what that feels like. This happens to me often enough that I stopped assuming it was just a busy week and started actually asking why.
The Bug Comes Home With You
Here's the shape it usually takes.
You spend the afternoon debugging something. You don't solve it. 5 PM arrives. You shut everything down and tell yourself, honestly, "I'll figure it out tomorrow."
Then, doing something completely unrelated: wait, what if the cache is being invalidated before the request finishes?
And you're debugging again. Nothing opened. No editor, no terminal. Just your own head, quietly still running the problem in the background.
The laptop is closed. The problem isn't.
Why Developers Specifically Get Stuck Like This
This isn't really a discipline problem, and I don't think blaming it on "bad work-life balance" gets at what's actually happening.
Most tasks have a natural stopping point. Development often doesn't. A weird bug, a failing test nobody's explained yet, an architecture decision you're not fully sold on, a PR you approved but still feel uneasy about: these don't come with a built-in "done" signal. Your brain keeps trying to complete something it perceives as still open, and it doesn't check the clock first.
Your brain doesn't care that it's 5 PM. It cares that the problem still feels unfinished.
There's real biology behind why this specific kind of unfinished-ness is so sticky. Your body's stress-response system (the hypothalamus, pituitary, and adrenal glands working together, generally shortened to the HPA axis) evolved to handle acute, resolvable threats: something happens, cortisol spikes, you respond, the threat ends, the system resets. Chronic, low-grade, never-quite-resolved problems, the kind a normal sprint produces constantly, don't give that system a clean resolution to reset against. So it stays partially activated longer than it would after a threat that actually concluded.
None of this means something is wrong with you. It means the kind of problem-solving this job constantly generates isn't the kind your stress response was originally built to close out cleanly.
"I'll Just Check One Thing"
This is where it usually sneaks past you.
"I'll just check Slack." One message. "I'll just glance at that PR." Twenty minutes gone. "Let me just try to reproduce that bug real quick." Suddenly it's 7:30 PM and you never actually decided to keep working. You just never fully left.
That's a different thing from choosing to put in extra hours. Choosing to work late is a decision. This is closer to never actually closing the door in the first place.
The Overtime Nobody Counts
Some overtime doesn't happen at a desk. It happens over dinner, thinking through an API design that isn't settled yet. It happens at the gym, replaying an incident from earlier in the week. It happens in bed, remembering the one thing you forgot to mention in standup.
Some overtime doesn't happen at your desk. It happens in your head. None of it shows up in any timesheet, which is exactly why it's so easy to not notice it's happening at all.
"But I Genuinely Like Coding"
Fair pushback, and I don't think the answer is "never think about code after hours."
Thinking about a problem after work isn't automatically unhealthy. Sometimes you genuinely love the problem. Sometimes the actual solution shows up on a walk, or in the shower, completely unforced. That's not the issue.
The issue is when you can no longer choose to stop. When the thinking isn't something you're doing, it's something that's happening to you, on a loop, without an off switch you can reach for.
The Real Problem: No Shutdown Ritual
Most developers have a clear start ritual. Open the laptop, check Slack, check tickets, open the editor, begin.
The evening version is usually just: close the laptop. That's it. No handoff. No capture. No clear boundary marking where today's unfinished business gets parked until tomorrow.
Your Brain Is Not a Todo List
If you leave work carrying "I need to figure out that timeout tomorrow" only inside your head, your brain keeps quietly re-surfacing it, because as far as it knows, nothing captured that thought anywhere safer.
The fix is almost embarrassingly simple: write it down properly before you close the laptop. Not "fix bug." Something closer to: what the problem actually is, what you already know about it, the specific next action for tomorrow, and its current status.
Your brain doesn't need to keep holding onto a problem once you've given it somewhere safe to sit until you're ready to pick it back up.
A Short Shutdown, Before You Close the Laptop
- Write down what's genuinely unfinished. Not in your head, actually written somewhere.
- Write the specific next action, not a vague restatement of the problem. "Check why the retry handler runs twice" beats "fix bug."
- Capture any stray thought that surfaces while you're doing this. Just write it, don't chase it yet.
- Decide honestly what's actually tomorrow's problem versus what can wait longer than that.
- Close the environment properly. Laptop, Slack, editor, all the way.
The goal isn't to forget the work exists. It's to stop carrying it around unnecessarily.
Weekends Aren't Automatically Safe Either
Saturday morning. No meetings. No tickets. Genuinely free time for once.
And then: "maybe I'll just work on my side project for a bit." Suddenly your only unscheduled day of the week has quietly become another sprint, just one nobody assigned to you.
Side projects, learning, open source, experimenting with something new, none of that is bad. But not every free hour needs to turn into another form of output.
The Guilt That Sneaks In
You rest for a couple of hours, and some part of you starts narrating: I should probably be learning something right now. You watch something for fun: I could be making progress on the side project. You just sit outside doing nothing in particular: this feels like wasted time.
When every hour starts feeling like a missed opportunity to improve something, rest stops feeling like rest and starts feeling like falling behind.
The Nuance Worth Keeping
This isn't an argument for building a hard wall between your brain and your work. Some days a bug will follow you home anyway. Some ideas really do arrive while you're making coffee, uninvited and genuinely useful. That's normal, and it isn't the problem this article is about.
The goal isn't a wall. It's a door you're actually able to close when you choose to, instead of one that's been left permanently ajar without you noticing.
Where I Landed
I used to think "switching off" meant everything was finished. Software doesn't really work that way. There's always another ticket, another PR, another bug, another framework worth learning, another way the side project could be better.
If "done" means everything is finished, that day never actually arrives.
Maybe the actual skill was never finishing everything. Maybe it's getting better at deciding which unfinished thing is genuinely allowed to wait.
Your job ends at 5. The bug can wait until tomorrow. The PR can wait. The thing you haven't learned yet can wait. The side project can wait.
You don't have to solve every problem just because your brain happened to remember it at 9 PM.
Sometimes closing the laptop isn't the end of the workday. It's the moment you actually let yourself leave it there.
What's the last work problem that followed you home, even after you'd already closed the laptop? Genuinely curious what that looks like for other developers. 👇
If what you're carrying feels heavier than what's described here, please don't sit with it alone; talking to a mental health professional or someone you trust is worth doing, and it's a sign of strength, not weakness.
Top comments (13)
My shutdown process is simple, say goodbye to my online collegue, then close my woking laptop down, say how are you? to my wife and thats all.
I like that. Maybe the best shutdown ritual isn't another productivity system at all it's simply having a clear moment where you stop being a developer and start being yourself again. 😄
Your shutdown list stopped me, because I recognized it line by line: what the problem is, what you already know, the specific next action, current status. That's not just a wind-down ritual - it's the exact schema of a good engineering lesson, and you've derived it from sleep hygiene instead of from incident reviews. Same shape, two directions.
Your question, honestly answered: the last problem that followed me home was a monitoring check that reported green over an empty dataset - the mean over zero measurements is zero, so "nothing measured" looked identical to "nothing wrong". It followed me around for an evening precisely because it wasn't written down yet; the loop closed the moment it became a note with a next action, not when it was fixed (that took two more days, and slept fine).
One addition from having institutionalized your ritual: writing it down only releases the loop if you TRUST the place you wrote it to come back to you. A note nobody re-reads calms you for one evening; the brain learns the trick and stops believing it. What made it stick for us was pairing the shutdown ritual with its mirror - the startup ritual reads yesterday's notes first, every time, so the capture provably survives the night. The door closes because you've watched it open again.
Curious about your last line, because it's the hard part: "deciding which unfinished thing is genuinely allowed to wait" - do you have a working criterion for that, or is it still judgment call by judgment call?
The exact schema of a good engineering lesson, derived from sleep hygiene instead of incident reviews is a better description of what that list actually is than anything I wrote. I hadn't consciously connected it to a postmortem template, but you're right, it's the same shape: what happened, what we know, what's next, current state. same discipline, aimed at your own head instead of a shared doc.
the monitoring bug is a genuinely good example of why some problems follow you home specifically. "mean over zero measurements is zero isn't a bug you can un-know once you've seen it, and it's the kind of thing that keeps quietly nagging precisely because it's conceptually simple and still wrong in production. the detail that it followed you for an evening and stopped the moment it became a note, two full days before it was actually fixed, is the clearest possible confirmation of the article's actual claim. the loop closes on capture, not on resolution.
the addition about trust is the real gap in what I wrote, and I think you're right that it's the harder half of the problem. a shutdown ritual without a startup ritual reading it back is just a diary entry. the brain isn't wrong to stop believing the note if nothing ever proves the note survived the night. pairing the two, so the door closing is provably paired with the door reopening, is a more complete version of this than what I described.
honest answer to your actual question: still mostly judgment call by judgment call, no clean criterion. the closest thing I've got isn't a rule, it's a question: does this get meaningfully harder or riskier if it waits until tomorrow. most things don't. the ones that do are usually the ones with a blast radius that grows while you sleep, which is a different category than most bugs, that mean-over-zero one included, since it was wrong the whole time either way.
"Does this get meaningfully harder or riskier if it waits until tomorrow" is more of a criterion than you're giving it credit for. It cleanly separates two classes: things that are wrong and getting worse (blast radius grows overnight), and things that were wrong the whole time - your framing of my mean-over-zero bug, which had been wrong for weeks and could safely stay wrong until Thursday. Judgment call by judgment call, but the question does the sorting.
On the startup half: the one mechanic that made read-back stick for us is brutal and small - the note must lead with the single fact tomorrow-you needs, in the first line, because morning-you skims. A note that starts with backstory is a diary entry wearing a to-do's clothes. The door-reopening ritual is mostly a formatting discipline on the door-closing one.
And: "the loop closes on capture, not on resolution" - if I ever write the startup-ritual half of your article, I'd like to quote that line with your name on it.
Fair you're right, it does more sorting than I gave it credit for. wrong and getting worse versus wrong the whole time either way is a cleaner split than judgment call implies, even if applying it is still a judgment call each time. a criterion that sorts two categories correctly is still a criterion, I was underselling my own line.
a note that starts with backstory is a diary entry wearing a to-do's clothes might be the single best sentence in this entire comment section. and it's a genuinely actionable fix, not just a diagnosis, lead with the fact tomorrow-you needs, not the story of how you got there. that's a formatting rule I can actually apply starting tonight.
and yes, obviously, quote away. that line came out of trying to describe what your monitoring bug story actually proved, so it's really yours as much as mine at this point.
The trade stands then - your diary-in-to-do's-clothes for my two-category split, both quoted with names on, and tomorrow-you gets the fact first. That's the whole thread in one formatting rule.
Guilty of this. Been coding very late until 4:00AM in the morning just because I like to code, it's addicting. I even shared it in Virtual Coffee and got the same advice to rest first:
But yeah, you are definitely right. We don't want to end up in an endless
whileloop without any condition to break out of it. Great read.Haha the while true energy is real. Honestly it's addicting is the most relatable part of your comment, that's exactly why willpower alone doesn't fix it, the same reason bugs stick in your head is the reason 4 AM feels fine in the moment. Good that Virtual Coffee called it out though, sometimes you need someone from outside your own head to say it. Get some sleep 😄
Refreshing article & how you broke down the biology behind the unfinished loop = 👍. I'll add this piece: In software, 'done' is an illusion, and peace of mind comes from managing your attention, not your output. 🫡
Not often but some nights I just DND and sleep 🥱
Exactly. I really like that distinction peace of mind isn't always about finishing everything, it's about deciding what deserves your attention right now. And honestly, some nights “DND and sleep” is the most productive decision you can make. 😄
my way of shutdown is "let it go~ let it go~ i dont want to see this anymore~" turn off wifi, turn off laptop and go do other stuff
Honestly Let it go might be the most effective shutdown ritual I've heard so far. Wi-Fi off, laptop off, and absolutely no negotiating with your developer brain. Sometimes the best way to close the loop is to stop trying to close it.