I've seen this kind of advice related to writing before. The idea is you may be working on a scene and it's almost all written/described/finished. You stop befo

I've seen this kind of advice related to writing before. The idea is you may be working on a scene and it's almost all written/described/finished. You stop before the end and move on to something else. When you come back to the scene, you'll be able to merge it into the rest of the story more easily now - perhaps even because you've realized what needed to happen after the scene (because you moved on to start that part before you had finished the first part). This is supposed to avoid the block of wondering, "so now what needs to happen next?" where your brain starts getting stuck in a loop of endless possibility because the search space has become unbounded. I do think this is one of those "easier said than done" kind of things, similar to "buy low, sell high." However I've had days where I've done the equivalent while coding. Say, while working on an increasingly large method and then stopping because I need some additional, independent functionality. So I put the big method aside and build that functionality only to come back and notice that I can now factor out some prior stuff in this big method and call parts of the other method I was working on.. and oh if I do that again, look - more things in common! And factoring just kind of happens all before I even knew exactly what the big method originally was going to do in the first place. (In some cases, the big method just disappears entirely and there's nothing left of it.) Of course if I could make this happen all the time on demand, I'd be golden...