This also applies to lots of things, you can quit, just do it after you made progress, regardless if it's shipping v0.1, running a marathon, etc. Don't quit when you're sad, get to a spot when you're happy then quit.
This also applies to lots of things, you can quit, just do it after you made progress, regardless if it's shipping v0.1, running a marathon, etc. Don't quit when you're sad, get to a spot when you're happy then quit.
If it's 6pm and I'm stuck solving a bug, I call it quits and go home. Often the next day I have a new perspective and check that other place where the bug actually comes from, and solve it faster than if I had just banged my head until late.
(1) Stop work when the immediate path forward is clear, so there is less friction to restarting.
(2) Stop work when encountering a puzzling obstacle, with the expectation that ambient thinking will suggest a path forward.
I try to do both of these things. I'm more successful with the second.
I first read about (1) in a book on writing technical papers, where the advice was to NOT write until you've become confused about the way forward. Rather, leave off so you know how to begin on the next writing session.
The right strategy could depend on the application!