Most developers code until they hit a wall or run out of energy.

There is a concept called the “Hemingway Effect” that changed how I manage my coding sessions, especially as a solo builder for my personal projects alongside a full-time Senior Software Engineer role.

Ernest Hemingway had a simple rule: stop writing when you still know what happens next.

The logic is simple. If you drain the tank completely today, starting tomorrow means facing a blank page (or an empty IDE) with zero momentum. The “cold start” is expensive.

But if you stop mid-feature (or even better, with a failing test that you know how to fix), your brain is already primed to pick it up immediately.

It feels counter-intuitive to stop when you are in the flow. We are taught to push through.

But leaving a task slightly unfinished creates a mental hook (psychologists call this the Zeigarnik effect). It keeps the context alive in your background processing.

Write down exactly what the next 3 lines of code should be. You will thank yourself the next morning when you can start shipping immediately instead of spending 30 minutes trying to remember where you left off.

If you try to switch to this approach suddenly, it might not work as expected. As most of us work on multiple tasks at the same time, a better starting point is to apply it to just one of them. Finish at a good stopping point, then resist reopening it.

It’s uncomfortable at first, but that’s kind of the point. Over time, it stops being an exercise and turns into discipline.

The goal is to never reach the state where you run out of energy. It’s an exercise.

Productivity isn’t just about speed. It’s about continuity.