Apparently everyone at a tech writers conference has impostor syndrome. It seems the deeply technical nature of documentation is partially responsible for writers to feel like impostors when working alongside skilled developers. That, along with deep API documentation and treating docs as code, were the three long running themes throughout WriteTheDocs 2014 held at the Crystal Ballroom in Portland, Oregon this past Monday and Tuesday. I don’t know of any other conference that can compete for the price paid. I most certainly got a solid benefit from my $100 corporate ticket.
Rather than try to translate/ regurgitate my own session notes in this blog post, I’ll point you to Andrew Spittle’s blog where he live blogged each session’s notes (seriously amazing skill there!) along with the page hosting the videos of each session if you care to check out one of the many amazing sessions presented at WriteTheDocs 2014 (currently only 5 are uploaded, more to come I’m sure!).
Instead, I’d like to highlight two takeaways from some of the key sessions using the above blog post and videos as deeper context where you may need it.
- Communities are awesome:
- Build community not minions. Work with your community on a common journey, not with intent to dictate.
- Deal with churn early and up front, as this will avoid more painful and damaging churn at the end cycle of the release.
- New Sheriff in Town:
- Deputize your vigilantes. They have an intrinsic motivation that can be channeled for good. Give them power to change and provide focus to channel that motivation to improved docs!
- Insert docs into product roadmap, dev, and life-cycle meetings. Remind all facets of the org that docs need to be treated as part of the product.
- Ignorance is Strength:
- Write docs by learning as you go. Use your ignorance to build meaningful docs from a new user perspective.
- Write anything, even if it is wrong. Having something written can give a framework for improvement/ updates.
- API Consumers are not who you think they are:
- Zapier.com has great developer documentation of their APIs which allowed an unexpected audience to develop a use for their service they hadn’t expected.
- Great developer focused docs which include text and screen shots / examples to explain the same concept in different ways.
- Wabi-Sabi Writing:
- Find beauty in the imprecise, the transient, the imperfect. But this is not luddism nor complacency.
- Less Faulkner, more Hemmingway: less flowery, more simple and clear. Less Coltrane, more Davis: economical restraint.
- Done is beautiful. (Art is shipped.)
- Strategies to fight documentation inertia:
- Talk to newcomers and beginners, ask them to write as they learn. Use “this section missing” stubs instead of blanks as motivators to complete that section by others.
- Social engineer motivation to edit/update with strategic but obvious errors to fix. Use low hanging fruit to entice editors to make changes.
- Improving Your Content’s First Impression:
- Community outreach for feedback- export docs to community and import content from community.
- Feed Stackoverflow questions in-line with documentation and embed feedback surveys.
- Better APIs through Empathy:
- Understand and share your user’s needs by using your own APIs.
- Use other APIs and read their docs too. This will help you write for your user, not for you.
- Ditch your CMS with Git and Static Site Generators:
- Build your docs like you build the product you’re writing about. Use iterations and version tracking, then simply auto-generate your content with build commands.
- Integrating developer tools provides consistency and familiarity across the development and docs process.
- Documentation as a Product:
- Like your product, answer the question: What problem are your docs solving?
- Documentation can be marketing. A sales differentiator. Good docs can lead to client satisfaction, but you need to measure sentiment.
The net/net of the 2014 second annual WriteTheDocs? Would go again. I had a great time and was able to pull out some solid (as well as esoteric) takeaways from a short, local two-day conference. The benefit of being able to attend locally made this conference a seriously valuable event for me. Icing on the cake? A friend visiting and also going to the conference as well which made the event even better for me (friends don’t let friends conference alone).