Im looking for a resources (ideally books) that can help juniors, devs and even seniors to improve their technical writing. To help them write better issue descriptions, announcements, documentations, user manuals and so on. How to communicate (in a written form) technical stuff to technical and non-technical people.
I am a professional technical writer. When I started out, I desperately looked for tips and tricks. Internet was (and is) full of tips but I could not find a tech-writing bibliography.
I will soon publish a bibliography of books and guides regarding technical writing. I promise to paste a link here when I am finished, which I believe I will be in a day or two.
It's rare someone follows up on a "I'll post this soon." Thank you for the excellent list! Quality books about writing are hard to come by; books about non-fiction are even scarcer. I'm looking forward to reading through your recommendations.
I just learned that tapping a comment's time let's you see the option for adding it to favorites. So thanks for that, and your future bibliography reference :)
Commenting because I don't know a great way to find this comment in the future otherwise.
I have a decent learning & development stipend at my job, and I've been looking to buy some hard copies of technical writing books so I can refer to them easily during the workday. And to intimidate my enemies on Zoom, of course. So far my go-tos are "Docs for Developers" and the classic "Elements of Style", which complement each other well, covering the newest documentation strategies and the oldest nonfiction writing strategies, respectively. I'd really like to start posting reviews to my blog as I read more and build out my own library.
I think all technical writing books are dry and boring.
The best books I've read that helped me with technical writing have been classic writing ones such as Ray Bradbury, Stephen King, Steven Pressfield, William Zinsser, and more.
Also following this general guideline from Orwell may help:
i. Never use a metaphor, simile or other figure of speech which you are used to seeing in print.
ii. Never use a long word where a short one will do.
iii. If it is possible to cut a word out, always cut it out.
iv. Never use the passive where you can use the active.
v. Never use a foreign phrase, a scientific word or a jargon word if you can think of an everyday English equivalent.
vi. Break any of these rules sooner than say anything outright barbarous.
Somewhat interestingly, Ted Chiang, in my opinion one of the best writers working in science fiction today, worked as a technical writer for Microsoft. However, he has said that they are very different and he doesn't feel one really impacts the other [1]. I'm not entirely sure I buy that, but it is interesting to see someone who's worked in both mediums talk about the connection.
You may also enjoy hearing that Thomas Pynchon spent a spell as a technical writer at Boeing. I've only been able to dig up one of his articles [1]. I assure you that it's worth the read.
The Minto Pyramid Principle is what you're looking for - https://www.amazon.com/NEW-Pyramid-Principle-Writing-Thinkin.... A timeless book on how to structure writing. Once you understand it, you'll start to notice applications of the book out in the wild. You'll also start to loathe writing that isn't structured as such because it's needlessly tedious and more difficult to understand.
The Minto Pyramid Principle is heavily used and recommended within Amazon, a company famous for their culture of written narratives.
I'm a Director of Software Engineering today, but early in my career I was a technical writer.
The #1 most important thing imho is know your audience. Who are you writing for? What do you know about them, or what can you reasonably successfully guess about them?
I once wrote a suite of manuals (yes, I'm that old) for an ERP software product. The audience was people on manufacturing shop floors, AP and AR people, sales people -- in other words, people who didn't know and didn't care about the underlying tech. They just wanted instructions to do their tasks. I learned their lingo and used it, and otherwise tried to write on a fourth-grade level.
At another company we wrote documentation that techs at wireline telephone companies used to install and operate our software. While these people weren't software developers, they were technical people and I wrote to them as such. I gave them the theory and concept behind things as well as the task instructions they needed.
The book discusses a variety of "soft" skills, including reading and writing. Not specifically focused on technical writing per se, but can still be very useful for engineers to learn how to influence others through written materials. As Urs Hölzle says in the foreword to the book:
"At some point in your career, you can no longer communicate effectively just by talking with others. Stand-ups, planning meetings, and peer programming sessions all have their physical limits. This effect applies to you sooner than you think. At that point, you need to switch to asynchronous communication techniques. In short, you need to switch to writing. Those who can write well suddenly have a head start. Through well-written communication, your influence suddenly grows exponentially."
If you're searching for more generic information on how to communicate technical content effectively to different audiences, check out this list of recommended books:
I second the request. I think communication is a drastically underappreciated skill even though we have all suffered due to poor communication professionally (undocumented libraries, poorly specified requirements, an inability to generate buy-in for our ideas).
I'll throw in a few recommendations I have from some recent research at work:
"Writing well" can mean two things: Putting together clear, concise, grammatically correct sentences that are pleasant to read; and organizing your content in a useful, rational way.
Technical writing needs to do both, and it also needs to teach well.
Teaching well doesn't always mean you're writing well, and vice versa.
Teaching well means using what cognitive and learning scientists have discovered about how best to teach adults.
Books like Strunk & White's Elements of Style are good resources for putting together good sentences. Fewer books teach organizing your content, and even fewer teach how to teach well.
Lisa Cron's book, _Wired for Story_, is aimed at fiction writers, but any type of writer can benefit from her book. She gives excellent cognitive-science-based reasons for each writing tip she gives.
I'm an editor/book project manager at a major computer book publishing company, and a former software tech writer. I recommend Lisa Cron's book to all my authors.
It doesn't answer your question, but for solutions that address the systemic issue at your organization, I offer two things that have been proven (in my life) to be effective:
First, without hiring more people, I would advise contacting your closest University and ask about graduate faculty who offer grant writing courses. For a small fee, they can provide training and materials for your staff.
Better, though, would be to target a non-technical grant writer and integrate that person into your team. Any communication for an exterior audience would flow through that person. I say non-technical, because that helps you avoid jargon and other "meaningless" items for exterior audiences. I also say specifically grant writer instead of technical writer because technical writers focus on ensuring all material is included, whereas grant writers also ensure that all material is digestible by human people. This person also learns your organization and can help target professional development for folks who might need it - it's all about creating a talent pipeline.
Source: I am a career grant writer, and any technical writing, especially areas as, for lack of a better word, arcane as tech writing can be vastly improved by succinct grant writers. I have contracted for companies in the past, but so few actually want to make systemic changes; mostly they want quick fixes and immediate solutions.
Good technical writing is good writing. Just learn how to write well in general. I recommend going through The Elements of Style and basically any college level writing course materials.
My top recommendations are "Docs for Developers" and "The Product is Docs".
I listed more books about docs and general writing, and TW courses and podcasts in this post: https://lorenaciutacu.com/resources-technical-writers/
The Elements of Style by Strunk and White is a short book of "rules" about style which boil down to making every word, letter, and punctuation mark "tell." I believe it to be essential to begin writing clearly and effectively.
"How to Edit Technical Documents" by Donald W. Bush and Charles P. Campbell is a pretty easy read that explains how to approach writing and structuring technical documents.
Edit: Some places have it priced pretty highly, but Amazon has it here for about $3:
I don't know of any "how to write tech. books" kinds of books. I do have some recommendations of good examples of technical writing and right on top of the list is the C programming language closely followed by anything written by Brian Kernighan. The latters relaxed presentation with hard hitting examples drives home points in a way that no other book I've read does.
Don't forget about diagrams! Words are important, but diagrams can really get concepts across. And not just the "technical" diagrams (sequence diagrams, flowcharts), but conceptual ones.
Not a book on technical writing per se, but Writing Without Bullshit (https://www.amazon.ca/dp/0062477153) can bring immense clarity and purpose to your writing.
De-bloating prose is essential to good technical writing, and this book teaches you that.
Not technical writing, but the best book I've ever read on writing (including Elements of Style etc.) is "Getting Published in International Journals: Writing Strategies for European Social Scientists".
On the surface it's aimed at academics who are non-native speakers of English, but in my experience most people could do with reading it.
I think the thing that helped me most was simply to learn more about English (I am a native English speaker) so that I could get an understanding of consistent tense, tone, narrative etc.
I suspect there are good general books on English writing but now I have learned how to write better, I can't believe I found it so difficult before.
> E-Prime (short for English-Prime or English Prime, sometimes denoted É or E′) is a version of the English language that excludes all forms of the verb to be...
Make It Clear by Patrick Henry Winston has a permanent place on my bookshelf. He breaks communication down into a structured system and applies it to a variety of forms including (beyond standard prose documents) things like decks, pitches, and lectures.
My AP high school English teacher taught me "garbage in, garbage out." His point was that if you want to write high level prose, you need to be reading the best prose stylists and be influenced by them. Read the best writers and stop reading garbage.
English professor here. This is the secret to becoming a terrific writer: exposing yourself to excellent writing. Nothing replaces this, and it works in every genre from technical writing to lyric poetry.
Who do you think are the best technical writers? I have a much better sense of who they are in literature, but in technical writing I'd like to read some examples.
Not necessarily a technical writing book, but one for writing non fiction: On Writing Well, The Classic Guide to Writing Nonfiction
by William Zinsser would be a very good read for everyone who wants to write.
it might be a little more on the practical "nuts and bolts" side of things vs. "how do i write well", but it covers lots of areas that always seem to come up when producing documentation for developers.
My advice: just write your documentation in dry bullet-list format. Soon there will be tools based on GPT-3-like networks that can turn these into beautiful prose :)
Many years ago I used this as the textbook in a technical writing class: Booth, Colomb, and Williams, The craft of research, University of Chicago Press.
I suggest reading Good With Words. The book good for any professionals who depend on effective communation. It is originally for created for lawyers, but it helped me tremendously at work as a software engineer.
URL: https://www.fulcrum.org/concern/monographs/1v53jz538
I keep a copy on my desk and thumb through it occasionally when I need help with my writing. Next to that book is also a copy of Williams and Colomb's Style: Toward Clarity and Grace. I've also read the USAF Tongue and Quill. There are good lessons in all 3 of these books for technical writers.
No idea why this got downvoted - most people's writing is so full of basic grammatical errors and bad habits they don't even realise they have. Finding such examples in your own writing is a great way to improve in my experience (whatever automated tools you choose).
I will soon publish a bibliography of books and guides regarding technical writing. I promise to paste a link here when I am finished, which I believe I will be in a day or two.