How to build quickly

Original Article ↗ Hacker News Discussion ↗

Relationship to Existing Concepts

  • Many see the method as a rebranding of known ideas: top‑down design, divide‑and‑conquer, tracer bullets, vertical slices, “progressive JPEG,” PDCA, breadth‑first coding.
  • Similar strategies are noted in books on writing/studying (“The Clockwork Muse,” “How to Read a Book,” “How to Read a Paper,” “How to Study”), and in learning science (Bloom’s taxonomy, deliberate practice, etc.).

Reported Benefits and Use Cases

  • Numerous commenters say they already work this way for:
    • Programming: defining modules/components, stubbing interfaces, then filling in details; good for mental modeling, testability, and motivation.
    • Writing: starting with outlines or bullet skeletons, then expanding; used for blog posts, academic articles, theses, and even fiction or D&D campaigns.
    • Personal productivity: nested TODO trees for indie projects; strong sense of progress as parent tasks collapse when children are done.
  • Iterative outlining is praised for:
    • Avoiding analysis paralysis.
    • Surfacing unknowns (parts that need further breakdown or research).
    • Letting people jump between high‑level design and low‑level details.

Tools and Workflows

  • People use plain text/markdown, outliners, note‑taking apps, task formats (e.g., obsolete markers), tree‑based TUIs, and IDE TODO tools.
  • Practices include aggressive pruning of outdated branches, mirroring today’s “speedrun” as tomorrow’s focus, and allowing dead tasks to “die off” rather than constantly rewriting the outline.

Quality, Design, and Paradigms

  • Supporters argue rapid end‑to‑end skeletons plus later refinement often produce better quality via iteration, and prevent over‑investing in low‑value details.
  • Others warn that “speedrunning” can:
    • Lock in poor architectures, tools, or algorithms.
    • Encourage under‑optimization and technical debt if the “go back and perfect” step is skipped.
  • Debate over programming paradigms:
    • Some claim functional programming’s avoidance of shared state makes this style easier.
    • Others counter that good modular design is possible (and common) in OOP and procedural code as well; FP only helps if used skillfully.

Limitations and Critiques

  • Not always suitable when:
    • The main difficulty is figuring out what to build or say, rather than executing.
    • You’re pushing hard technical boundaries and must first de‑risk key unknowns.
    • Writing is used as the primary thinking process; outlines may be repeatedly discarded.
  • Concerns include context‑switching overhead, over‑investment in outlines, difficulty scaling to larger teams, and the risk of producing formulaic or “filler” work if the underlying ideas are shallow.