技术写作与文档2015scottmeyers.blogspot.com
写《Effective Modern C++》所需的时间
The Time Needed to Write “Effective Modern C++”
导读
这篇博文围绕《Effective Modern C++》的写作耗时展开，让读者看到一本专业技术书背后需要投入的时间。对写作者来说，它不只是出版八卦，而是提醒你估算长项目的周期，并思考“给建议”的作者需要怎样的实践背书。
可以直接用的写作要点
- 01
技术书写作往往是长期项目，动笔前要为资料整理、反复修改和验证预留足够时间。
- 02
写建议或指南类内容时，作者最好有亲手实践的完整案例支撑，否则读者会质疑其权威性。
- 03
把复杂主题组织成“读者容易犯错的清单”，是一种降低学习成本的有效结构。
- 04
用同类经典书的篇幅和写作周期作参照，可以帮助自己更现实地估算写作投入。
HN 评论精选
给写作建议的人最好有亲手实践的完整作品，否则权威性会被质疑。
这位作者真的在实际项目里写 C++ 吗？他常以 C++ 教会使徒自居，但我总惊讶他似乎不把这些准则应用到任何实际项目。作为程序员，当一个人只给我看代码片段却从不展示完整项目，却不断给意见时，我会怀疑。就像一位从不缝衣的裁缝大师。为什么他获得那么多认可？我更愿意接受像 Carmack 那样有成功 C++ 项目的人的建议（很多人认为 Doom 3 代码是漂亮的 C++，但其中的选择很有争议，远非“现代”）。我也把 Stroustrup 归入同一类。
mpu查看英文原文
Is this guy actually writing C++ programs in the wild? He often presents himself as an apostle in the C++ church, but, I am always surprised that he does not seem to apply his guidelines into any practical project of his. As a programmer, I'm suspicious when people have opinions and give advice but never showed me more than snippets of code. Like a master tailor that wouldn't sew. How come he gets that much recognition and respect? I would be much more inclined into accepting advice from someone like, say, Carmack, that has successful projects in C++ under his belt. (Many people consider Doom 3's code beautiful C++, yet, the choices made there are very controversial, and far from "modern".) I also put Bjarne Stroustrup in the same category. What do you think?
复杂主题可以写成避坑指南，但这也暴露了主题本身的复杂成本。
我以写 C++ 为生并且喜欢它，但让我不安的是，我们需要一本本质上在列“你很容易不小心搞砸，当心！”的书。目前看来，C 表达力不够，其他语言又太慢，但 C++ 的复杂性令人担忧。
blt查看英文原文
I write C++ for a living and I like it, but it bothers me that we need a book that's essentially a list of "you can easily fuck this up by accident, watch out!" for now, it seems that C is insufficiently expressive and everything else is too slow. but the complexity of C++ is troubling.
用经典技术书的篇幅和周期作参照，能帮助估算写作投入。
我想知道 Kernighan 和 Ritchie 写《The C Programming Language》花了多久？Amazon 说第二版（1988）有 272 页，但回想起来感觉只有 80 页 :) 按原文作者的计算（语言创造者的效率是两倍）大概 4 个月？
curiouslurker查看英文原文
I wonder how long it took Kernighan and Ritchie to write 'The C Programming Language'? Amazon says the 2nd edition (1988) is 272 pages long but looking back, it felt like it was 80 pages :) Going by the OP's math (of the language creator being twice as productive) prolly 4 months?
同类还值得读
编写更好文档的框架
A Framework for Writing Better Documentation
这是 Divio 的文档写作框架，把技术文档按「读者的目标」分成四类：教程（学习导向）、操作指南（问题导向）、参考（信息导向）、解释（理解导向）。
技术写作与文档2021 · 637 分 · 76 评4 条写作要点编辑精选写好一份设计文档
Writing a good design document
这篇 HN 帖子标题为《Writing a good design document》，主题是如何写好一份设计文档；对写作者来说，它值得作为技术写作和结构化说明文的参照。
技术写作与文档2025 · 581 分 · 147 评3 条写作要点编辑精选技术写作课程
Technical Writing Courses
这是 Google 官方免费技术写作课程（两门），讲受众定义、主动语态、短句、文档结构等基础方法。
技术写作与文档2020 · 571 分 · 73 评4 条写作要点编辑精选写出更好的错误信息
Write better error messages
这篇帖子讨论如何写出更好的错误信息，评论补充了开发者场景下的具体做法和真实反面案例。
技术写作与文档2022 · 566 分 · 253 评4 条写作要点编辑精选写一本技术书的经济账
The Economics of Writing a Technical Book
一位技术书作者拆解写书的真实经济账：版税收入往往远低于投入的时间成本。
技术写作与文档2018 · 519 分 · 149 评4 条写作要点编辑精选