エンジニアによるドキュメント作成（ユーザーガイド、運用手順書、APIリファレンス、設計書など）について、架空のプロジェクトを例にして順を追って解説されている。
ドキュメントの種類・書き方・考え方の概念的な方法論や教訓が、ある程度高いカバー率で網羅されている。基礎的な知識・原理を身につけることで長い目
...続きを読むで見て役に立つ知識を得られるものであり、これを読んですぐにそのままマネすれば良い、というものではないと思う。
実務でエンジニアがやりがちな失敗や「考えが及んでいなかった」というケースへの言及が多く、経験者としては耳が痛いし、それゆえに学びが多い。
文量が多くて時間がかかりそうだったため、全体的に見出し・太文字を中心に飛ばし読みをしたが、それでも十分に学びがあった。もし見出しだけで著者の意図や根拠を読み取れない・納得できない場合には本文を熟読すると良いだろう。また後で時間があるときに本文の熟読をしたいという読後感を持った。
42ページ
ユーザージャーニーマップ
→作り手はユーザー体験を考慮しないことが多い。あるいは考慮しようとしているのに考慮できていないということも多い。利用者や読み手に優しくないモノを生産しがちなので、この問題に対する答えのひとつがユーザージャーニーマップなのだと思う（本文を読んでいないのでこの解釈で合っているかは自信がない）。
56ページ
・できるだけガイド単体で読めるようにしましょう。ユーザーが必要とするすべての行動を1つのページにまとめておきましょう。
→これは本当にそのとおりで、ほかのページと行ったり来たりすることの煩雑さを考慮するべき。できればリンクを飛ばずに単体で完結するほうが最も望ましいが、構成次第ではやむをえずリンクをつけて往復させることもあるだろう。また、たとえばWikiとファイルサーバのように異なるプラットフォーム上で往復させることも避けるべき。リンクを貼ること自体はやっても構わないが、リンク先の概要・サマリー表やスクリーンショットなどをリンク元に貼るようにしたい。
83ページ
最も重要な情報を冒頭で述べる
→これも本当にその通りで、できていない人が多い。仕事においては「起承転結」よりもPREP法（POINT→REASON→EXAMPLE→POINT）を使いましょう。ストック的なドキュメントだけでなく、メールやメッセージでも結論を先に書きましょう。長々と何行も文を書くときに下から2行目くらいに結論を書くのはやめてほしい。
177ページ
タイトルと最初の段落の両方に、ドキュメントの目的と、読み手が達成できることを書いておきましょう。
→やるべき。考えなしに作ると省きがちだが、読み手はまずそのドキュメントの位置付けを理解してから内容を読まないと正しく解釈できないので、位置付けや意義を早い段階でわかるように作るべき。 
どうしても後手にまわりがちなドキュメント作成。その重要性を訴え、エンジニアの業務から地続きのところでのHowを描き、運用時に発生する課題までをカバーした一冊。