About writing, Ernest Hemingway had this to say:

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. That is the most valuable thing I can tell you so try to remember it.

You should always stop when you know what happens next.

This has nothing to do with stopping, by the way. It has everything to do with the difficulty of starting again. The unspoken premise of the quote - the part of the iceberg that's below the water, to just keeping rolling with Papa - is that inertia is powerful, and getting started is the hardest part.

If you know what happens next, then starting again is easy.

And once you're rolling, you've got momentum.

I've written a novel, and I've written software big and small. These are completely different skills but a lot of the frameworks, processes and pitfalls are similar. Just like a novel, a software project develops threads and themes and patterns and a voice. You want to produce in a sprint, a month, a quarter a thing that is logically consistent and emerges at a consistent pace so you and your teammates (editors) can shape it, critique it and hone it.

For me, when I apply this to coding, I try to end each session when I know exactly what work needs to be done next. For example, towards the end of the day on a project to build a new product page, instead of trying to squeeze a few more lines of code out or fixing a bug, you might stop and write the following note to Future You:

Next step: Add inventory to the product route.

• fetch inventory
• render it on screen
• interstitial (spinner) and error handling
• think about retries and caching, probably not but at least explore it and make notes
• observability and monitoring, how will we know if it's down, add a test or two
• come back to that bug in the product description

And it's there for you at the start of the next day.

Contrast this to how many of us work, which is trying our hardest to completely finish something every session. Often ending up either with a mad dash to the finish that burns you out for the next day, or failing and falling short which bums you out for the next day.

Here's what the two ways of working look like visually:

That's your work until it's done pattern in Red, and then Hemingway's system in Green.

The important two things to note are that Red had a cold start at the beginning of a task four out of the five days (compared to one on Monday for Green), and that Red had to push extra hard (maybe getting to work early or staying late) on Friday while Green had a more evenly paced week.

A trick to this system is to make the first task an easy one to get you going with a win. So in the above example, only start by fetching the inventory if the endpoint is known, you already have the creds, you already have patterns in your app for fetching etc. If not, I might start by mocking it and putting it on the screen. Piece of cake.

A potential benefit to this system in software - and I don't have any data to back this up, but I have a strong gut feeling that it's true - is that a significant number of bugs are written and patterns violated when we're stretched and stressed. The traditional way of working produces two stressful states that the Hemingway method avoids: The cold start at the beginning of a session, and the rush or grind to finish a deliverable at the end of a session.

Finally, it should be noted that Hemingway's technique can be applied at multiple levels of regress. Hemingway wrote daily, so the advice came from the perspective of stopping one day and picking it up the next. But you can apply it to your morning session and your afternoon session. Or to pomodoros, or maybe most realistically to those days when you have 8-10 to code, then you have meetings, lunch, more coding 1-2, another meeting, then finish out the day with a third coding session from 3-5. Finish each coding session at a good stopping point, and then spend the rest of the time writing out exactly what comes next.