Book review: Docs for Developers: An Engineer’s Field Guide to Technical Writing
Gyanesh T.
Technical Writer | NLP and Python | OpenAPI | REST Docs | Swagger | OAuth | Conversation & Prompt Design
You may have seen the poll I have circulated about the upcoming posts in The Content Gym newsletter and asked you to vote for the next topic you would like to read about. Although the poll is still going on (do vote) - I thought I will just get the book review article leading the votes so far out of the way, as the information is fresh in my head from reading the book. So, read on:
I was quite pumped to read this book due to excellent credentials of the writers - I was expecting I will get to read about creating the latest and future help experiences. Why? Cause the writers of this book are working with precisely that in their main jobs and the title said: Docs for Developers. And Dev Docs happens to be the thing that one must (I can almost hear some may say it's not a must to do it) be proficient in in the era of Docs as Code and Cloud.
Did I get what I was expecting?
Not really.
But the answer lies in the subtitle of the book: An Engineer’s Field Guide to Technical Writing. Instead of enabling technical writers to be better in creating docs for developers, the book is about enabling developers to document their own code by learning best practices of technical writing. The book encourages developers to document their tech well and support the tech with good documentation.
Should I read the book still?
Yes. If you are a developer and wondering - "why or how should I even document my tech?" This book will give you a framework and tools to enable you to come up with good documentation and take your tech to a bigger audience. Most of the stuff explained in the book is what an experienced technical writer would already know about technical writing and documentation.
Is there no value for technical writers in this book?
Although the book is better suited for the audience we learned about above, there were useful and good bits of information that I liked. For example - many of us can benefit from understanding and following the below:
领英推荐
What would be a better resource for a technical writing trying to acquire skills?
I think an experienced technical writer will derive better and instant value in looking at (and trying to reverse engineer) the following dev doc sites, which use the in-demand tech and methodologies we ought to acquire or at least consider:
And there could be more - but this is enough to keep us occupied for a while with the subject.
Conclusion
Buy this book for a developer friend or colleague of yours who you want to become more aware of technical writing. Such people may be few though as developers will rather build than document.
If you have read a book or another resource on this subject (dev docs) that you liked, do share with the community in the comments.