There is one pattern that I’ve seen it in 25 years of working in IT, across technical writing roles, developer advocacy work, and conference speaking. Engineering teams build things they care about and understand deeply, and then struggle to explain them to people who are encountering those things for the first time. The gap between “we built this” and “you can use this” is almost always a documentation gap.
At Write the Docs conferences — I’ve spoken there, and the community continues to shape how I think about this work — you meet people who have felt this gap from every angle. Developers frustrated by their own team’s docs. Technical writers trying to change documentation culture in organizations that treat docs as a compliance task. Developer advocates who see the community confusion that incomplete documentation creates. Everyone is working on the same problem from a different position.
Doc4Docs exists to make the case, in plain terms, that documentation matters and that better documentation is achievable. Not through a proprietary system or a special tool, but through clear thinking about what users need, consistent application of principles that are already well-established, and the discipline to treat documentation as a practice rather than a task.
The name is simple: Doc4Docs is short for “documentation for documentation” — a site about documentation, clearly labeled. But I also think of it as “doctor for documentation.” Every product that has users and poor documentation has a diagnosable problem and a treatment plan. The diagnosis is usually not complicated: missing quickstart, no examples, confusing structure, mixed content types. The treatment is usually not complicated either. What’s missing is the attention and the priority.
This blog is for people who care about documentation: technical writers, developer advocates, developers who want to write better, product managers who’ve realized that the documentation is part of the product. The posts will be practical, occasionally personal, and honest about what’s hard.
Twenty-five years in, the problem is still everywhere. So is the opportunity to fix it.