On finishing projects
Finishing personal software and creative projects often proves harder than starting them, prompting wide-ranging reflections on motivation, process, and what “done” really means. Commenters highlight tactics such as defining a clear end state, writing specs, timeboxing, tracking visible progress, working in public, and using accountability partners, while also stressing the need to distinguish between projects meant for learning or play and those intended for release. Many note that accepting imperfection, narrowing focus, and aligning projects with genuine personal goals are crucial to overcoming perfectionism and endless tinkering.
Defining “Done” and Whether Projects Ever Finish
- Several comments stress “knowing what done looks like” up front; “done” is a compromise where it’s good enough to ship, even with imperfections.
- Others argue software is never truly finished: it just reaches a state where it no longer needs tending, or becomes “dead software” when it’s never used again.
- Some see launching as distinct from finishing: you set small release milestones with tests/docs, but development can continue indefinitely.
Motivation, Discipline, and Emotional Friction
- Many struggle with long tails of projects and half-finished ideas, and with guilt about them.
- One camp emphasizes “grinding it out” to build the muscle of finishing, becoming more selective about what to start.
- Another camp relies on external accountability: small groups, meetups, or an accountability partner.
- Some explicitly reframe projects as either “product-focused” (must be finished) or “process-focused” (learning/tinkering, no guilt if unfinished).
- ADHD and mental health issues are mentioned as relevant to difficulty finishing.
Planning, Specs, and Working Modes
- Multiple posters endorse writing specs or plans during high-energy periods, then coding against them on low-energy days.
- People describe operating in different “modes” (e.g., programmer vs. CEO hat) and using journaling/Obsidian to track cycles, health, and habits.
- Timeboxing and deadlines are widely seen as useful, though some dismiss this as just standard agile practice.
Shipping vs. Keeping Work Private
- The article’s emphasis on public release draws mixed reactions.
- Some argue working in public should be a default; “every action brings release” once you accept that mindset.
- Others strongly reject the idea that public release is required for “done”: many private projects are considered complete for personal learning or use.
- A middle ground is putting experiments in public archives without promotion, to mentally close them.
Concrete Tactics and Heuristics
- Suggested tactics: outline/MVP first (“tracer bullets”, “outline speedrunning”), end-to-end but minimal versions, Kanban-like limiting of WIP, and ruthless deletion of low-value ideas.
- Progress metrics (“number goes up”) work for some, but finding good proxies for creative work is hard.
- Anti-perfectionism themes recur: redefine “perfect” to include done, accept “half-assed but shipped,” and avoid polishing past the point of improvement.
Process and Culture Critiques
- Debate over Agile vs. older Japanese quality practices: some see agile as misused and low-discipline; others defend its focus on timely, high-quality delivery.
- Several criticize over-optimization of productivity (timers, status meetings) and remind that people are not “widgets.”