I used to close my laptop at 6 PM and forget about code until the next morning.
Now I close my laptop and my brain keeps compiling.
I'm in the shower, and suddenly I know why the test was failing.
I'm at dinner, and I'm mentally refactoring a function I wrote three days ago.
I'm lying in bed at midnight, and I'm debugging a problem that isn't even real. It's a hypothetical edge case I imagined while trying to fall asleep.
Nobody warned me about this part of getting better.
Everyone talks about the learning curve when you're a beginner.
Nobody talks about the learning curve that happens after you get good.
The paradox nobody prepares you for
When you're starting out, code is something you do.
You sit down. You open the editor. You write. You Google. You struggle. You close the laptop. Done.
Code lives in one place: the screen.
But something changes as you get better.
Code stops being something you do and becomes something you are.
Your brain starts noticing patterns everywhere. A login form on a random website makes you think about session handling. A slow-loading app makes you wonder about their caching strategy. A conversation about a restaurant's reservation system turns into a mental whiteboard session on race conditions.
You didn't ask for this. It just happened.
And the better you get, the more your brain does it. Automatically. Involuntarily. All the time.
Why this happens (and it's not just you)
There's a reason senior developers seem to never stop thinking.
When you're a beginner, your brain spends energy on what to do. Syntax. API names. Which library.
When you become experienced, those things become automatic. Your brain frees up capacity, and that capacity doesn't sit idle. It goes looking for problems.
That's what makes you valuable as an engineer. It's also what makes it hard to rest.
Your brain has been trained to spot inefficiencies, edge cases, and potential failures in everything it sees. Including things that aren't code.
Including your own life.
Including a conversation with your partner about what to have for dinner.
You don't consciously choose to think about caching. It just happens.
And that's the trap.
The three stages of switching off
I've noticed this pattern in myself and in almost every developer I've talked to.
Stage 1: You can switch off easily.
You're early in your career. Code is a task. When the task ends, your brain shuts down. You can watch a movie without thinking about work. You sleep fine.
Stage 2: You can switch off, but it takes effort.
You're mid-level now. Code is a craft. You care about it. You think about it in the shower. You dream about it sometimes. But a good weekend, a good workout, or a good meal can reset you.
Stage 3: You can't switch off. You can only pause.
You're senior now. Code is part of your identity. There's no off switch anymore. There's only a background process.
The problem is that Stage 3 feels like success.
Until it doesn't.
The cost nobody talks about
Here's what happens when you live in Stage 3 for too long.
You stop being present.
You're at your kid's school event, but your brain is mentally reviewing a pull request. You're on a date, but you're half-thinking about that flaky test. You're on vacation, but you're checking Slack just in case.
The people around you feel it. You feel it. But you can't stop.
Your best ideas come at the worst times.
The solution to the bug you've been stuck on for two days arrives at 11:47 PM, right when you're finally falling asleep.
You get up. You write it down. You can't sleep now because your brain is awake.
Rest stops feeling restful.
You take a day off, but you don't actually rest. You just do less work while still thinking about work. The laptop is closed. The brain is not.
Your identity gets too tight.
When code becomes who you are, any threat to your code feels like a threat to you. A bad review. A failed deploy. A junior developer questioning your approach. These stop being technical events and start being personal ones.
That's when burnout starts.
Not from working too many hours. From never being able to leave the work behind.
What actually helps (from someone still figuring it out)
I'm not going to pretend I've solved this. I haven't. But here's what's helped me move from always on to mostly off.
1. Give your brain a different problem to solve.
Your brain doesn't want to stop. It wants to redirect. So give it something else.
Learn an instrument. Cook a complicated dish. Play chess. Read fiction, especially fiction that has nothing to do with tech.
The goal isn't to silence your brain. It's to give it a new playground.
2. Make the transition physical, not mental.
You can't decide to stop thinking about work. But you can change your physical environment, and your brain will follow.
Close the laptop. Put your phone in another room. Walk around the block. Change your clothes.
Rituals matter. Not because they're magic, but because they signal to your brain that this context is over.
3. Write things down, but only once.
When an idea hits you at midnight, write it down in one place. Not in Slack. Not in your head. Not in three different notes apps.
One place. Then let it go.
The act of writing it down tells your brain that it's captured, and you can release it.
4. Stop treating rest as a reward.
Rest isn't something you earn by finishing everything. Rest is something you need to keep functioning.
You wouldn't skip sleep to finish a feature. Don't skip rest to feel productive.
5. Accept that you'll never fully switch off, and that's okay.
You don't need a perfect off switch. You need a way to come back to yourself.
Some nights you'll still think about code. Some weekends you'll still check your phone.
That's fine.
The goal isn't to become someone who doesn't care about code.
The goal is to become someone who cares about code and can still be present for everything else.
The truth nobody says out loud
The skills that make you a great engineer, like pattern recognition, curiosity, obsession with edge cases, and the inability to let a problem go, are the exact same skills that make it hard to switch off.
You can't turn them off without turning off the thing that makes you good.
So the question isn't "How do I stop thinking about code?"
The question is:
"How do I make space for the rest of my life while still being the kind of person who thinks about code?"
That's not a technical problem. That's a life design problem.
And like any good engineering problem, it doesn't have a perfect solution. It has a good-enough solution that you keep iterating on.
If you're reading this at 11 PM and you just closed your laptop and your brain is still running, you're not broken. You're not weak. You're just good at something that's hard to put down.
The same brain that keeps you up at night solving imaginary bugs is the brain that makes you valuable in the morning.
You don't need to shut it off. You just need to teach it when to rest.
Now I'm curious, and I know I'm not the only one here:
What's the last thing your brain refused to stop thinking about, even when you weren't at your desk?
Was it a bug? A design decision? A weird edge case you imagined at 2 AM?
Drop it in the comments. I promise you're not alone. The weirdest ones are always the most relatable.
Top comments (15)
The 'write it down, but only once' suggestion seems useful because it separates having an idea from accepting a task. I'd be careful with the three-stage ladder, though: presenting 'can't switch off' as the senior stage risks making a boundary problem sound like a promotion requirement. A midnight note can remain a note until working hours. Do you find the harder part is capturing the thought, or resisting the urge to open the editor and act on it?
Thanks for this You're right about the three-stage ladder. It wasn't meant as a promotion checklist, just an observation of a trap I've fallen into myself. And I'm glad the write it down once tip resonated.
To your question: capturing the thought is the easy part. Resisting the urge to open the editor at 2 AM is what actually gets me. Out of curiosity, what's been your experience with that?
I don't have a personal 2 AM example to add, so I shouldn't present this as something I've solved. Your distinction makes me wonder whether the note needs a return time as well as the idea: 'look at this tomorrow after lunch' gives the unfinished thought somewhere to go. Opening the editor would then be a separate choice, rather than the next step in capturing it. Would that help in your case, or does setting a time just keep the task active?
I really respect the honesty in that first line. And honestly, the return time idea is brilliant.
I think giving the thought a scheduled destination, like tomorrow after lunch actually works better than just leaving it open-ended. It turns a vague later into a concrete not now but then. For me, that wouldn't keep the task active in a stressful way. It would just put it in a queue with a clear execution time.
I'm definitely going to try adding a return time to my notes. Great suggestion!
As a solo founder this hits even harder — there's no "end of shift" when the product is yours. Last one for me: a user flow I'd shipped that morning kept replaying in my head all evening until I found the step people were dropping off at.
The "write it down in one place, then let it go" tip is the only thing that's actually worked for me. Once it's on paper, my brain stops guarding it.
Madan the solo founder angle is something I didn't even consider when writing this, and you're right. There's no end of shift when the product is yours. The user flow bug replaying in your head all evening is such a perfect example because it's not even a bug you can fix anymore. It's already shipped. Your brain just doesn't accept that.
And I love that 'write it down in one place then let it go worked for you too. You said it better than I did: Once it's on paper my brain stops guarding it. That's exactly it. The note is proof to your brain that it doesn't have to hold onto it anymore.
Thanks for sharing this genuinely. Solo founders carry a specific kind of weight that doesn't get talked about enough.
Exactly that. The shipped-bug loop is the worst kind, because there's nothing left to do except accept it, and that's the hardest part.
The note trick has stuck for me. Small win, but it's the difference between actually being present in the evening or half-debugging in my head. Thanks for writing this one, Harsh.
You nailed it with nothing left to do except accept it. Acceptance is always the hardest part because our brains are wired to solve problems not let them go. Half-debugging in my head' is such a perfect way to describe that feeling.
Really glad the note trick is working for you. Thanks for the great conversation, Madan
This hits incredibly close to home. When you first start coding, you leave your bugs at your desk. But as you get better, you start seeing the whole world as an architecture problem. Your brain just doesn't stop optimizing or refactoring in the background, even when you're trying to sleep or walk. That shift from 'solving a syntax error' to 'system-level thinking' is exactly why it becomes so hard to switch off. Thank you for putting this invisible tax of expertise into such perfect words!
Yashish invisible tax of expertise is such a perfect way to put it. You're right the shift from syntax errors to system-level thinking is so gradual that you don't notice it until you're already in it. Thanks for reading, and for this comment. Was there a specific moment you noticed that shift in yourself?
For me, it was when I caught myself evaluating a restaurant's queue system as a rate-limiting and load-balancing problem instead of just waiting for food! That's when I realized my brain had stopped looking at code as just a screen job and started looking at the whole world through an engineering lens.
I'm having the exact opposite experience right now. It was hard for me to switch of in the beginning, but now, after six and a half years, it's relatively easy. There are a couple of things that did the trick for me:
Find something in your free time you truly care about. For me, music and reading have always been things that make me happy, and this makes switching of easier. I don't listen to music because I need to rest. I listen to music because I love music
Learn mindfulness meditation. One of the biggest things for me. Meditation is the most effective mental rest I've ever come across. Nothing organizes my thoughts and rests my mind more. And it has numerous benefits, like making it easier to be present, making you less judgmental, more content...the list goes on
Write everything you have to do for work down. This has also been a big help for me. I keep detailed notes about everything I do at work in OneNote on my work laptop. When I have a thought in my free time, I pull out a piece of paper, write down the thought, put it on my desk somewhere I'm gonna see it next day and move on with what I was doing before. If you write everything down you are not worrying about forgetting anything. Write everything you need to remember down somewhere you're gonna see it easily when it comes time to work again. It has saved me a lot of headaches
Identifying less with my work. This is a hard process to go through. I'm still going through it, and I'm still falling down at times. But as the say in "Software Engineering at Google": You are not your code. The problems at work are something you have, not something you *are.
Keep up working on it. It is the journey of a lifetime, but you can definitely get better at switching of if you actively work on it.
Andreas, this is such a valuable counterpoint. Thank you for sharing it.
I wrote this from the perspective of someone still figuring it out, so reading that it genuinely does get easier after six and a half years is honestly reassuring. It gives the article a hope I didn't give it myself.
A few of your points really landed:
The meditation one I've heard this from several developers now, and I think I've been avoiding it because it sounds too simple. But 'nothing organizes my thoughts and rests my mind more' is a strong endorsement. I'll give it an honest try.
And You are not your code' from Software Engineering at Google that quote alone reframes the whole problem. The idea that the problems at work are something you have, not something you are. That's the line I wish I'd had when I was writing this.
Thanks for the detailed reply. Comments like this make the article better than it was when I published it.
The beginning feels tooo relatable.
Haha glad it's not just me. That brain keeps compiling feeling is the exact thing that made me write this. Thanks for reading! Which part hit hardest for you?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.