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...
Or, more generally, know what you're going to work on next, and have enough context to hit the ground running. If you get to the office / update your repo / etc. and have to spend half an hour figuring out what to work on next, you're not going to carry any momentum over.
I find a more effective version of this trick is to leave some "gimme" task for the next day. I always try to make sure I leave some easy, 15-minute task for the next day. That doesn't mean I don't complete what I'm currently working on however...
I don't know about always stopping when I'm going good, but I almost always leave myself with a concrete "next step" for the next day when I do decide to stop. Sometimes this means getting the task I'm working on to 95% completion, or forcing myself to work a bit longer so that one of tomorrow's tasks is already started and approximately roughed out (tests written or methods stubbed or HTML roughly laid out).
If the day's boundary falls on a major task boundary, the next day starts with me figuring out what to work on next - not nearly as conducive to "getting into the groove" as tying up a few loose ends and then jumping on whatever I need to work on next.
do you ever start planning what you're going to code next while you're falling asleep, or when you take a toilet break or walk somewhere? or when you go to a meeting and sketch out that new module or whatever?
reminds me of a hemingway hack. it's hard to sit down to my computer with no specific goal in mind, or just the high level "i have to finish this story" in mind. it's easy to slide into other things.
but if i've been visualizing the code i want to write, or if i have a sketch of the data or algorithm, then i don't waste time.
I fail to see how this helps to "avoid being stuck," in fact it seems more likely to result in you sitting looking blankly at half a page somewhere in the middle of the day.
Exactly. This advice might apply more to a creative process, where original thought counts above all else. I imagine being truly creative is an exhausting activity, knowing several professional artists (oil paint). You're basically holding a large set of options simultaneously in your head and try to make unique connections between them. The value is not in how many iterations of connections you go through, but coming up with something unique at all.
Development strikes me more similar to solving cross-word puzzles, or playing mine-sweeper, where activity is more guided, focused along a smaller set of options, with lots of trial and error in the process: it's sort of "focused play"/ experimentation. Here it seems more valuable IMHO to keep on going once you're in the flow. You're not looking for that one special connection, that will make your day, but are solving many little problems that aggregate over time.
I could imagine science-based development work to be creatively exhausting as well, where you're trying to prove some theorem etc. Hemingway's advice might apply itself nicely in this case.
I'd like to see more blog posts on how to solve different types of problems. E.g. I know that walking away from a hard problem after you're exhausted works out well (the subconscious keeps on working on it), or as Hemingway proposes, walking away right before you become exhausted.
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...