Huh - turns out this is quite a pointed description of something I think I already subconsciously tried to achieve for some time without being really able to define it.

I usually try to build quite extensive documentation and task trackers for every project I am attempting. Now that I read this article I think a lot of it is indeed the feeling of knowing what to do next immediately after an arbitrarily long break and preventing the feeling of being "finished" just because I completed one feature/subtask.

Certainly worth trying to optimize for what the article is describing - does anyone has experience with this in a more general fashion (writing is a very unique thing IMO) or regarding software projects?

I get this natural high when I find a breakthrough in a problem. My brain gets amped up and I literally can't focus and finish because of the buzzing sensation. I know it's my cue to get up from my desk and take a walk, usually a 10 to 20 minute walk until my brain settles down.

So having had this happen so much I've come up with an analogy. I love riding my bike and where I live it's really hilly. The best part about hills in this case is that fits the stopping when the going gets good: I change gears when I first climb a hill, making it easier to climb; once I'm close to the top the consistent effort I put into hill climbing pays off. This is where I get to stop pedalling.

Likewise, when working once the answer is there before you, stop, take a break and let your brain coast as it rewards itself with sweet dopamine for doing a good job.

To continue with the analogy, finishing a hard problem is like letting the potential gravitational energy do the work for you. It gives you chance to recuperate and focus on the next hill in front of you.

> The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel, you will never be stuck.

This is always hard. When things are going well (in flow, on a roll etc.) you want to continue and get it all out. When you get stuck in writing, programming or anything, taking a break seems to make sense after a few moments of toil.

Yes and besides things happen during the next day, that doesn't mean you'll want to get going again, regardless of how good of a state you left progress in.

Maybe it’s like anything else... to get into an activity you have to get some quick wins scaffolding. So you set it up from your previous day but not something insurmountable. But the same could be true if you were just starting on a new problem. A large reward/effort ratio motivates you to see what else you can get. And that’s true regardless of whether you were the one who set up the problem the day before.

In a somewhat similar fashion, I often try to leave a failing test when I take a break. It makes it easy to get back into the code when you come back. You have a well defined problem that is easy to inspect. You also have a feeling of a lack of closure. It's easier to think to yourself, "Well, I'll just get this code working" and once that happens you'll have gotten into the flow. If you leave all your tests passing, when you come back from your break you have to decide what's next and then push yourself over the energy hump to actually do it.

I was just reading about programmer's block / writer's block. This Quora answer https://www.quora.com/Do-programmers-suffer-from-Writers-Blo... gives a few helpful tips such as just write some functions to get you going and get the program to show output as quickly as possible (hello world, failing unit tests, whatever). Stopping when you've done the hard work of figuring out what to do next seems like a good technique as well. I don't think you should interrupt yourself mid-task though vs. pausing when you're ready for the next logical piece.