I've always appreciated Stephen King's advice on writing. So much so that I once bought a jacket with a tiger on the back because he suggested that it was a good way to build confidence as a writer¹ (see George Stark in The Dark Half). Another piece of advice from King is this handy rubric for editing: "cut 10%"... or in the words of his high-school era editor:

“Not bad, but PUFFY. You need to revise for length. Formula: 2nd Draft = 1st Draft — 10%. Good luck.”

This is solid advice, but as you might guess there is a lot more to editing than making things shorter.

In the recent months, I have been working with @calebhailey.com to develop a new kind of workflow for posting to the Internet. Traditional social media has problems with content ownership, but what they get right is the user experience.

It is trivial to open up Twitter or Instagram or Facebook or LinkedIn or any number of other sites using their mobile app and make a quick post hit send and have it go live on a public facing feed somewhere on the Internet that other people can see.

Doing something this basic is unfortunately quite difficult if you own your own website and domain. Caleb and I think that’s a problem, and that you should be able to post to your own website as easily as you post to Twitter.

Key Words and Phrases: documentation, knowledge sharing, engineering culture, technical writing, user experience (UX), product culture

Background

For those of you familiar with my community and professional work—as a co-founder and organizer of the Write The Docs conference (2013-2015), as an outspoken advocate for documentation, and as the Technical Lead (TL) of Twitter's internal TechDocs team (2014-current)—this publication may come as a surprise. It is precisely these professional experiences which have led me to the understanding that I have today: that documentation may in fact be more harmful than it is helpful.

Further Discussion

While writing these articles, I asked my coworker Greg Poulos (@gregpoo) to take a pass at proofreading/editing. He had some good feedback and questions, which I thought I should tack onto the end of this series of posts.

NOTE: This is the third article of a three-part series. The first part discusses strategy while the second part explains how to grow a TechDocs team.

How to Grow a TechDocs Team

Getting a handle on technical documentation is an essential part of any software project, yet this fact seems to get forgotten by most companies during their staffing discussions. Rarely does a tech startup co-founder think to hire a technical writer as part of their initial engineering team. Many companies do not even have a single dedicated person on documentation. So, let's start there.

NOTE: This is the second article of a three-part series. The first part discusses strategy while the third part wraps up with some more in depth discussion.