On finishing projects

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.”