> Exiting after hitting a “neat” stopping point - unless the task is done, leaving the system / code too clean makes it hard to know what to work on next. While it’s really tempting to try to stick the landing on an internal milestone, it can often be more productive on net to stop just short of a neat milestone as an onramp to your next coding session.<p>I have heard novelists talk about similar strategies: end your writing day knowing what the next thing you need to write is, but not actually writing it. So, the next day, you can sit down and get going immediately, and use that momentum to launch you into that day's work.<p>I think I do the opposite. I most often reach a flow state when there's something wrong, and I'm trying resolve it. It's repairing the broken state that absorbs me. When I get to that resolution, the challenge is having enough self-awareness to stop: I look up, and afternoon turned into night, my shoulders are cramped, my neck hurts, but hey why not keep this going?<p>Even after resolving the problem, the <i>overall</i> state of the application is still "broken", i.e. incomplete, so I always have something to bring me back.<p>The thing for me, as a former-professional programmer, current hobbyist, is that it's easier to reach a flow state if you care about what you're working on, and get wrapped up in it. If you're working on some corner of an application you don't care about except for the paycheck, you probably have a harder time getting motivated. So, what works for me may not work for everybody.