Daniele Procida - Always complete, never finished

Documentation work often gets trapped in long, detailed planning cycles that delay publishing and amplify anxiety—leaving teams with “work in progress” that’s out of date before it’s ever usable. Daniela Procida’s core claim is that documentation should be treated as “always complete, never finished”: it can be complete enough to publish at every stage, while still evolving continuously. That mindset matters because documentation isn’t a ship under construction; it’s a product need that becomes urgent the moment users require it.

Procida distinguishes the pain of necessary effort from the pain of avoidable frustration. Writing itself is usually manageable—turning knowledge into readable text. The real suffering comes from deciding what to document, in what order, how much to write, and when to stop, then restarting when plans fail. The deeper driver is the belief that nothing is valuable until the whole plan is executed. In complex documentation projects—especially during restructuring—plans become brittle: product details shift, other contributors commit changes, and entire sections can become obsolete mid-flight. The result is labor without reward: long stretches where nothing publishable exists, even though the product is “crying out” for documentation.

She argues that the planning trap is fueled by confusing “finished” with “complete.” A framework she’s associated with—often mistaken for a blueprint—should instead function as a guide for checking direction, not a mandate to produce a comprehensive plan. The alternative she proposes borrows from “well-formed growth” in living organisms. A plant grows in stages that are always appropriate to its size: each moment is structurally correct for where it is, even though it’s not mature yet. Applied to documentation, this means iterative evolution from the inside out: small, well-scoped improvements that immediately increase usefulness.

Her practical workflow is deliberately tiny. Pick something small already in hand—often a page, section, paragraph, or even a single word—critique it against documentation standards (especially user need, language, and logic), then choose one next action that produces an immediate improvement. Repeat the cycle quickly. This approach reduces the emotional burden of being responsible for unfinished work that won’t matter until a distant “finish line.” It also supports restructuring: transform content in place through incremental steps, postponing large transplant operations until the material is robust enough to survive.

Procida illustrates the method with two examples. For a new documentation project, she built documentation for a Python model of a 35mm film camera. Instead of drafting a full outline, she published early and iteratively—adding a “get started” proto tutorial, reference sections, test instructions, and expanding explanations as the code evolved. For restructuring, she describes prior failed attempts to reorganize pytest documentation using large refactoring-style plans. The successful shift came when she and the pytest community agreed to small commits and rapid review cycles, trusting that each incremental change would collectively evolve the structure. In both cases, the work felt “complete” at each stage—useful and coherent—while still clearly unfinished.

The takeaway is a workflow principle: optimize for completeness of each incremental step, not completion of a grand plan. By nurturing “frogs and French beans” rather than chasing delivery of a final form, teams can publish sooner, adapt to change, and reduce anxiety while improving documentation steadily.