How to build quickly
A popular productivity essay argues that you can build software, write, or learn far faster by sketching a complete end‑to‑end outline and then recursively refining it—akin to “progressive JPEGs,” tracer bullets, or classic top‑down design. Commenters largely agree this breadth‑first, divide‑and‑conquer approach helps avoid paralysis and supports iteration, but note trade‑offs: it’s harder to scale in teams, can encourage under‑engineered “MVP” junk if you never return to polish, and only works well once you already know what you’re trying to say or build.
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.