I also do this. I learned that if I leave a failing test for myself in the morning, I'll think about it on and off and jump right in next session without wasting time on HN or YT for an hour or 2 in the mornings. Sometimes this ends up causing me to work a little bit late, trying to make sure I actually have a failing test written for the problem (sometimes I have an issue without an accompanying test yet), but it's worth the extra effort/time. A failing test gives me something 100% actionable to jump into in the morning, as opposed to leaving e.g. a feature half written which can have an ambiguous starting point in terms of jumping back into it. I can't recommend this enough.
Ive heard a similar idea, from Hemingway.
"Learned never to empty the well of my writing, but always to stop when there was still something there in the deep part of the well, and let it refill at night from the springs that fed it. I always worked until I had something done, and I always stopped when I knew what was going to happen next. That way I could be sure of going on the next day." — Ernest Hemmingway"
I really agree, and I also thinks it can be helpful to do something similar when taking breaks (have lunch/take a walk while leaving a failing test).
I was super in the other camp. Could not sleep if something wasn’t finished. Especially for coding. For marketing I found a (good) blog post can take a couple of days.
I'm similar, but for me it's i can't sleep if i don't understand the issue. Once i understand it enough that i've either fixed it in my head, or i'm confident i can fix it with the available knowledge, then it doesn't bother me.
"Understand it in my head" is often a good stopping point too. Because if i actually go and fix it, i may find out i was wrong and spend even more time re-analyzing the issue to reach a new understanding.
I used to get into loops with that - I thought I understood something, then I'd try to implement it and hit a corner case, or even a caveat would come to my mind, and suddenly my understanding is crashing. I developed anxiety around this, because thinking and rethinking would mean I could spend days without anything to show for it (other than a thousand lines of semi-coherent ramblings in an Org Mode file). I started to lean towards taking things simple and direct, solving them more by feel than explicit analysis, in order to create a bedrock of something I could then iteratively improve or rewrite, without having to keep the entire problem in my head at all times.
I've posted about this here before but the thing I do it type out a single easy thing I need to do directly in the code so it breaks the syntax. Then the next day I can read the note, delete or comment it out to fix the syntax and then implement the thing. It is a good dopamine boost right out of the gate.
I use this same trick, to ensure I resume right where I left off. Works great! Also helps me jump right back in, don't have to go looking for a problem/rabbit hole.
I once heard this advice given as "park facing downhill." I find it difficult to not finish up before I stop working, but it helps me get started in the morning to jump into a nearly-complete task.
I also do this. I learned that if I leave a failing test for myself in the morning, I'll think about it on and off and jump right in next session without wasting time on HN or YT for an hour or 2 in the mornings. Sometimes this ends up causing me to work a little bit late, trying to make sure I actually have a failing test written for the problem (sometimes I have an issue without an accompanying test yet), but it's worth the extra effort/time. A failing test gives me something 100% actionable to jump into in the morning, as opposed to leaving e.g. a feature half written which can have an ambiguous starting point in terms of jumping back into it. I can't recommend this enough.