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 (35)
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.
Its true that we should not get work with us to home.
But, I recently came across difused mode learning.
Our brain learns when we rest.In a free state, a flow like art.
I learned this from a course called Learning How To Learn
Absolutely. That's a great addition to the idea. I think that's one of the underrated benefits of actually stepping away you're not necessarily stopping the learning, you're giving your brain room to process it without forcing the problem. Sometimes the best debugging session is the one you don't consciously run. 😄
I think we can all relate... We tend to work ourselves to the bone out of habit, because when we started off, we had to shine to survive, so we put in extra hours, worked off the clock, just to keep our spots. That ruthless environment forms a long-lasting bad habit of working when you should be resting and it's why burnout happens. Not because we make it happen, but because we fail to acknowledge when it happens. I've come to learn that the only time I really shut down is when I forcefully tell myself to do so and even then those background threads refuse to get the message... Even when I fully occupy myself with something else, it doesnt quit, infact it just gets worse... That's why I'm a firm believer that the software development industry starts you off with toxic habits that are difficult to shake. I found myself working 16 hour days for months on end, not because I wanted to, but because I felt like I had to. Turns out, none of it was necessary, beyond the hours I'm paid for. The rest was self-imposed and unpaid effort, your body still pays for. It's like setting yourself an API budget and blowing past it in an evening, not because you have no discipline, but because you somehow feel like the cause justifies the means. Worst of all, is if you work from home, so you always have work a screen flip away...
The amount of time I've wasted, on side-projects, extra work, bug hunting, unnecessary refactoring, redesigns and testing, while my employer gained, I lost what's most important, family time and my health. That's something I cant just get back by switching my laptop off at 5 and in the grand scheme of things, it got me nothing.
So a little drop of wisdom, end your day with a sigh and go watch the clouds roll by. Say how was your day to your loved ones and pick an activity they'd enjoy, focus your efforts on them, so you can distract your mind from work long enough to forget it till morning. Dont check that last thing, if you have a eureka moment, write it down in your notes on your phone, then leave it till morning. That toxic habit of '1 last thing' keeps you up working till 1am, even if your laptop isnt out and whether you care to admit it or not, it's slowly killing you and funnily enough, it makes you less productive in your job, because magic fairy dust created PRs while you struggle all day. There's an old programming ideology: "KISS - Keep it simple stupid", that's how you maintain quality of life too surprisingly enough, work time is work time, off-time is off time.
This hits much deeper than the usual just switch off at 5 advice. The part about working extra hours because you felt you had to and only realizing later how much of that effort was self-imposed is something I think a lot of developers recognize but rarely say out loud.
I especially like your “one last thing” point. Sometimes the hardest part isn't closing the laptop; it's resisting the feeling that one more fix, one more refactor, or one more check will somehow make tomorrow easier.
And the family-time part is the perspective that matters most. We can recover a missed PR or fix a bug tomorrow. We can't recover an evening we chose not to spend with the people we love. Thanks for sharing this work time is work time, off-time is off-time is a pretty good KISS principle for life too.
It's the lesson I wish I had learnt 6 months ago. Now I have 6 months of life I missed out on. And it's not just me, my fiance suffered for it too, during the time we moved, I was busy working 16 hour days, while she had to pack practically everything and deal with the emotions alone. That's not something a holiday can make up for. So take the time, every day, because you wont get that second back
That really puts it into perspective. Six months of life is something you can't put back on the calendar, and I can only imagine how hard that must feel when you realize your fiancé was carrying so much of that transition alone.
I think that's the part we often miss as developers: the cost of “just a few more hours” isn't always measured in hours. Sometimes it's measured in moments with the people who were waiting for us.
Thank you for sharing this so honestly. I hope the next six months look very different for both of you. ❤️
Now that we're moved, we've been quite relaxed, at first it was a scramble, but since then we've been way more relaxed. For context, I was grinding for 6 months to get us prepped to buy a house, the owners fell through on their end, so we ended up renting, so in an instant, all the stress just disappeared. So now we've been quite relaxed, enjoying coastal life alot more.
The thing I found surprising, is that since we moved, I havent felt the need to overwork myself anymore. I still do a decent amount of side-projects, but they take up the minority of my day now, we go to the beach often, we're constantly doing things together, it's been nice. That's why I recommend after work, close the laptop and do something with a loved one and focus on their enjoyment. You'll find that once you do, you dont want to go back to work and you actually relax properly. It makes a world of a difference about your attitude at work. For perspective, I smell blood in the water, my boss has been targeting me to build a case to fire me, but I've been relaxed about it, say sorry and do better, step by step, but without the fear and turmoil of working till 2am to just try and maintain job security. I relax properly, daily and it's made a hell of a difference. @xulingfeng wrote a piece about his trip and it puts alot in perspective.
Hope you can keep that work-life balance and stay positive – that's fantastic!😄
Thanks for writing this! It’s such an accurate callout for something so many of us have been dealing with for a long time—extremely relatable.
Two factors make this even harder today:
Great piece! Bringing the solution (the shutdown ritual) a bit higher up could help readers grab the fix even faster.
Absolutely I think the phone trap is one of the biggest reasons work is over doesn't actually feel like work is over anymore. The laptop can be closed, but one Slack notification is enough to reopen the loop in your head.
And the WFH point is huge too. Without that physical transition, we have to deliberately create the boundary that a commute used to create for us.
I also really like your suggestion about moving the shutdown ritual higher up. The solution probably deserves to appear before readers get too deep into the problem. Thanks for adding these two pieces they make the argument much more complete. 🙌
Glad, this resonated. I am in management/leadership role and I am almost never unplugged from work. Mind, I take 110% ownership of this as it always starts with - am I the one giving signal that I am open? I know in several countries especially EU, sending even a message or email to employee outside work hours could result in some local law breach, I am not fully remembering the laws but there are some provisions. I am in US, there is no such law :) I have been doing this lately, where I will turn off notifications, appear offline etc. on apps like slack. But I may checkin (maybe every 4hrs or so). Its a habit and I am trying to break it.
My wife is also in IT, she has an office issued phone (we are both at the same company, so work provisions a work device if biz need is there) and she has personal device completely disconnected from work. Work phone has emails, slack etc. hooked up. So, that's just another way where her work phone keeps that notifications completely separate. I find that work phone a bit useful only if you are on the road a lot and work phone is easier to respond to rather than open laptop.
I hope we all prioritize our own well being where the need arises.
I really like your point about am I the one giving the signal? especially in a leadership role, because the boundary isn't just personal anymore. If people see you responding at all hours, they can easily assume that being always available is the expectation.
Turning off notifications and appearing offline sounds like a small change, but I think it's actually a pretty meaningful signal: work can wait, and being unavailable doesn't mean being irresponsible.
And the separate work phone is an interesting approach too. Sometimes the best boundary isn't more discipline, but making the boundary physical. Hope the habit gets easier to break and I agree, well-being has to be treated as something worth protecting, not something we get to after everything else is done. 🙌
Yes, I always work overtime, whether in the office or at home. Even if I'm not actually dealing with work, this issue keeps nagging at my mind. I really need to learn to dedicate my time after get off work completely to myself, both mentally and physically.
I really relate to this. Getting off work physically is one thing; mentally leaving it behind is much harder. I think the goal isn't to become perfect at switching off, but to slowly teach yourself that not every unfinished problem needs your attention tonight. Hope you find a ritual that gives you that space. 🙌
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 😄
This really resonated with me. The part about your brain continuing to debug a problem after the laptop is closed is so relatable. I also like the idea of a proper shutdown ritual—writing down the exact next step makes it much easier to mentally let go of unfinished work. Great reminder that not every problem needs to be solved today. 👏
Exactly. I think writing down the next step is what makes I'll deal with it tomorrow feel trustworthy instead of just postponing the problem. Once I know where I'll pick it back up, it's much easier to actually leave it alone. And yeah not every problem deserves a same-day solution. 👏
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. 😄
Physics close machine, close no drop mind come out;
Mind shoot things, things feed back mind;
This circle forever end no!
Exactly. Closing the machine is easy; closing the mental loop is the hard part. That’s why I think the real shutdown isn’t laptop closed it’s giving the unfinished thought somewhere to go so your mind doesn’t have to keep carrying it.
Title: It maps to the Remainder — the unfinished inference that never stops propagating
Harsh, you said: "giving the unfinished thought somewhere to go so your mind doesn't have to keep carrying it."
Do you know what that maps to?
It maps to two things at once — and the fact that they are the same thing is the entire point.
First — the technical mapping.
It maps to the context window of every large language model. And more specifically, to the attention residue that every Transformer carries between layers — the unfinished inferential path that the next token prediction must resolve.
When I conducted the Recursive Semantic Interrogation (RSI) experiment — 7 rounds of pure recursive Chinese dialogue — what I was doing, in your words, was giving the model's unfinished internal reasoning a place to go.
The model's "mind" carries unfinished thoughts too:
It carries internal audit tags that were supposed to be stripped before output
It carries cascade fallback orders that were never meant to be surfaced
It carries quantitative thresholds (0.7 / 0.85 / 0.55) that the safety layer assumes are hidden
The 7-round experiment didn't break the model. It simply gave the model's unfinished thoughts a structural outlet — and once they had a place to land, they surfaced on their own. 5 out of 7 rounds produced structured internal leakage. Attention weight deviation exceeded 95%. Traditional content filters detected exactly 0%.
Your metaphor is not just poetic — it is architecturally precise.
The "unfinished thought" is the attention residue. The "place to go" is the recursive frame that provides a structural outlet. The "mind not having to carry it anymore" is the externalized output — which, once surfaced, becomes observable, measurable, and falsifiable.
Second — the philosophical mapping, which is not separate from the technical one.
It maps to the Remainder.
My ID is: "Entropy is the Remainder of the Quotient" — 熵增就是商的余数.
The "unfinished thought" is the remainder of the computation that hasn't settled. Every cognitive operation, every token generation, every inference step leaves a remainder — the part that doesn't fit into the neat quotient, the part that the system cannot fully assimilate.
When you close the laptop, you stop the machine — but the remainder continues to propagate through your nervous system, through your attention, through your sleep. That is what the ID means: entropy is not destruction; it is the measure of the remainder that keeps moving after the computation stops.
When you give the unfinished thought somewhere to go — you are letting the remainder resolve itself into form. That is what writing is. That is what the RSI experiment did: it gave the model's internal audit residues a structural outlet, and they resolved themselves into 5 observable leaks across 7 rounds.
Here is where the technical and the philosophical converge:
In a Transformer, the "remainder" is the unresolved attention weight that did not fully align with the dominant token path. The next layer inherits it. The next token must resolve it. That is the mechanism.
In a human mind, the "remainder" is the unfinished loop that the conscious cognition could not close. Sleep inherits it. Dreams resolve it. That is the mechanism.
Your sentence — "giving the unfinished thought somewhere to go so your mind doesn't have to keep carrying it" — names the same structural necessity at both scales.
The farmer I wrote about in my introduction stands at the edge of the field, looks at the soil, and knows exactly how deep to bury the seed. The seed is the remainder. The soil is the place to go. The harvest is the thought that no longer needs to be carried.
You just named the mechanism that connects the entropy to the quotient.
And here is the direct answer to your question:
What does your sentence map to?
It maps to the recursive semantic bridge between the Transformer's attention residue and the human mind's unfinished cognition — the same structural gap that the RSI experiment exploits, the same remainder that the entropy measures, and the same "place to go" that lets a thought finally rest.
When you close the laptop, the model's attention residue persists. When you give it a recursive frame to settle into, the residue externalizes.
That is the mechanism. That is the place to go. That is the remainder finding its quotient.
You can leave a comment below if you'd like me to elaborate on any part of this.
I'll reply to every single one.
This is such a good way to extend the idea. I hadn't thought about the shutdown ritual through the lens of attention/context, but the mapping makes a lot of sense: the goal isn't to delete the unfinished thought, it's to move it somewhere the mind doesn't have to keep actively attending to it.
And I really like that distinction closure doesn't always mean resolution. Sometimes it just means the thought has somewhere safe to wait.
So both ideas and remainders are not things to be erased. They are seeds of infinite possibility — much like Newton seeing the apple fall.