写作方法2018ybrikman.com
写作与编程的10:1法则
The 10:1 rule of writing and programming
导读
这篇文章提出写作与编程的“10:1 法则”：最终成品背后，往往是十倍以上的草稿、删除和重写。写作者值得一读，因为它把“反复删改”从挫败感变成正常的工作量；评论区还补充了两个提醒：增删行数不等于真实写作量，以及作品真正完成的标准是读者能读懂。
可以直接用的写作要点
- 01
把删改当成写作的主体：10:1 法则说明成稿背后有大量草稿和删除，时间应主要花在改，而不是只写第一稿。
- 02
改稿时不要只做“平移”：挪段落、换词会产生大量增删记录，却不等于真正的重写，要有针对性地打磨表达。
- 03
别用字数或行数衡量写作投入：统计口径会重复计数，判断标准应是稿子有没有被反复推敲过。
- 04
以读者能读懂作为完成标准：就像代码要能被同事读懂一样，文章写到读者不费力就能理解才算写完。
HN 评论精选
版本控制的增删行数不等于实际写作量，移动段落和改词会被重复计数，前提站不住。
问题在于，16 万行插入和 13 万行删除并不真的意味着他写了 16 万行文字。版本控制系统里，任何一次编辑都会被记成插入加删除。写书的过程是先写草稿，然后大刀阔斧地重排、改词，但你不会把每个词改十遍。挪动一段话会很快产生大量增删行，可我不会把这算成重写了那些行。改一个词也会让整行变动（因换行而重排更会引发大量编辑）。所以我不太认同这篇文章的前提。
lmilcin查看英文原文
The issue here is that those 160k insertions and 130k deletions don't really mean he wrote 160k lines of text. The way VCS works, any edit would register as an insertion and deletion. The way writing a book works, is you write some kind of draft and then mercilessly edit by rearranging things and changing words. But you don't change every single word 10 times. Moving stuff around creates a lot of edits very quickly -- moving a paragraph creates many lines of insertions and deletions but I would never count that as rewriting all those lines. The same goes for editing words -- changing a word will change entire line (insertion/deletion). If this also rearranges paragraph (due to line breaking) it may cause a lot of edits. So I don't really buy into the whole premise of this article.
把插入和删除相加是算错了，正确关系是总插入=现存行数+总删除。
不是要否定整体观点，但这个算法是不是有点问题？第一个例子里他给出 16 万插入、13 万删除，就说自己写了 16 万+13 万=29 万行文字。这……不对吧？他写的是 16 万行。要写成等式的话，应该是 16 万（总插入）=3 万（当前规模）+13 万（总删除）。
mrosett查看英文原文
Not to detract from the good overall point, but isn't the math here a bit wonky? In the first example, he shows 160k insertions and 130k deletions and claims that therefore he wrote 160k + 130k = 290k lines of prose. That's... wrong? He wrote 160k lines of prose. If you want to express it as a sum, it's 160k (total inserts) = 30k (current size) + 130k (total deletions.)
可读性是持续交付的前提；写作也一样，完成的标准是读者能读懂。
对！而且如果每一行代码被重写 16 次，想想它被读了多少次（每次重写要读好几遍，还有 PR 评审）。换句话说，程序能跑、客户满意不算完；要等其他开发者能读懂才算完。否则你就没法继续让程序跑下去、让客户满意。
z5h查看英文原文
Right! And if each line of code is (re)written 16 times, imagine how many times it's read. (several times each rewrite, and PR review) In other words, your work isn't done when the program works and makes the customer happy. It's done when other developers can read it. Otherwise you can't continue making the program work and make the customer happy.
同类还值得读
被低估的工程技能：把文章写好
Undervalued Engineering Skills: Writing Well
这篇文章讨论为什么“写得好”是被低估的工程能力，以及它如何在团队协作、系统设计和职业发展中持续带来回报。
写作方法2019 · 1,109 分 · 371 评4 条写作要点编辑精选每行只写一句话：让写作和修改都更轻松的排版法
Writing one sentence per line
这是 Derek Sivers 的一篇短文，主张写作时每行只放一个句子，而不是按段落排版。
写作方法2022 · 849 分 · 297 评4 条写作要点编辑精选书面沟通是远程工作的超级能力
Written communication is remote work super power
这篇文章讨论远程工作中书面沟通的价值，评论区则补充了异步与同步沟通的适用场景，并提醒读者：备忘录、结论先行、结构化命令格式等书面沟通传统早已有之。
写作方法2020 · 831 分 · 190 评4 条写作要点编辑精选如何写出有用的文字
How to Write Usefully
保罗·格雷厄姆在这篇文章里给"有用的写作"下了一个可操作的公式：有用≈重要×新颖×正确×清楚，任一项为零，整篇文章就等于零；他还主张敢下确定判断、删掉让自己心虚的句子。
写作方法2020 · 821 分 · 285 评4 条写作要点编辑精选如何写得更清楚、想得更清楚，并学会复杂材料（PDF）
How to write more clearly, think more clearly, and learn complex material [pdf]
这份 PDF 讨论如何把文章写清楚、把思路理清楚，并用写作来学习复杂材料。
写作方法2022 · 779 分 · 153 评4 条写作要点编辑精选