Leave work slightly unfinished for easier flow the next day
Leaving code “slightly unfinished” at the end of the day is framed as a way to make it easier to re-enter flow the next morning, with techniques like leaving failing tests, deliberate compile errors, or TODO comments as breadcrumbs for future work. Many engineers report that stepping away before completion lets their subconscious process problems overnight and reduces the friction of restarting, while others say incomplete work causes stress, insomnia, or clashes with their need for closure and clean handoffs. The broader exchange highlights how productivity tactics are highly personal, intersecting with factors like excitement about end goals, work-life boundaries, and team expectations around “low-impact” but necessary tasks.
Core idea: leaving work slightly unfinished
- Many describe deliberately stopping when the next step is obvious (“slightly unfinished, but fully understood”) to make it easy to re-enter flow the next day.
- Some liken it to “parking facing downhill” or writing techniques where you stop mid-stream so you know exactly what to do next.
Reported benefits
- Reduces morning friction: you start with a small, well-defined action instead of a blank slate.
- Helps preserve a mental model overnight and quickly rebuild context in complex codebases.
- Ending after finding a root cause but before writing the fix lets you sleep on the solution and sometimes spot subtler issues.
- Some say their “night mind” continues processing, producing insights or even full solutions by morning.
Costs and when it backfires
- Several say any unfinished task causes rumination, insomnia, or a sense of dissatisfaction; they prefer strong closure.
- Those with difficulty “turning off” (including possible ADHD) report that unfinished work dominates thoughts outside work.
- Concerns about user impact: leaving a nearly-finished fix can delay value and occasionally wastes customer time.
- Some argue quality may drop at end of day; others report the opposite, saying late-day code is higher quality while context is fresh.
Concrete implementations
- Leave code non-compiling on purpose: missing delimiters, partial statements, or a plain-language line in source so the compiler points to where to resume.
- Leave a failing or non-compiling test as the next action (mirroring TDD advice to stop after writing a failing test).
- Use uncommitted or cleanup-later comments / TODOs that describe clearly what to do next and where.
- Some prefer a small, under-an-hour task queued for the morning rather than half-finished work.
Sleep, offloading, and notes
- Many recommend “emptying your brain” into notes, comments, or sticky notes to offload context and reduce anxiety about forgetting.
- There’s disagreement on whether writing things down supports later subconscious processing or causes forgetting; most see it as helpful.
Broader productivity and work-meaning debate
- One subthread argues that if you’re truly excited by your end goals, you don’t need productivity tricks; others counter that most real jobs include substantial boring but necessary work.
- Another subthread critiques “saying no to low-impact tasks,” noting that avoiding unglamorous reliability or maintenance work can make someone a poor teammate, even if it sometimes benefits their career in certain organizations.