写作方法2008lambda-the-ultimate.org编辑精选
尼尔·斯蒂芬森：程序员即写作者，第一次就要写对
Neal Stephenson: Programmer as a writer. Do it right the first time
导读
这篇围绕 Neal Stephenson 提出的“第一次就做对”展开，评论者用即兴表演、代码重写和写作草稿经验来检验这一说法。对写作者的价值在于：它把“初稿质量”问题从单纯技巧转向直觉训练、目标澄清与重写策略，并提醒小说写作和大型编程并不相同。
可以直接用的写作要点
- 01
初稿不满意时，先问清自己原本想达成什么，再果断丢弃重写，而不是在坏稿上反复修补。
- 02
写作常需要一稿专门用来理清思路，第二稿从零重写往往比逐句编辑更有效。
- 03
像即兴表演那样训练即时产出：专注当下场景或问题，信任自发联想，先不评判地写下来。
- 04
不要简单照搬编程的“第一次做对”：写作容忍模糊、可随内容调整目标，但也意味着要主动管理细节和方向。
HN 评论精选
即兴表演训练说明，高质量即时产出来自对场景的专注、信任自发想象和不评判。
Stephenson 的想法——通过培养潜意识只产出高质量内容，从而第一次就生成高质量作品——让我想起即兴表演。即兴场景可以是一个小品，也可以是一整部音乐剧，没有剧本或计划；演员上台后一次一句地说、演、唱最先想到的东西。糟糕的即兴很多，比如业余的、为了廉价笑声硬造噱头的；但我也见过惊人的即兴：整部戏剧和音乐剧，有时主题严肃，连贯且高质量到不像是即兴出来的。我曾看过一整部阿尔弗雷德·希区柯克式“电影”在舞台上即兴演出，竟达到希区柯克标志性的诡异与世故优雅的结合。我受过约三年即兴训练，它很像 Stephenson 说的要让打字机色带不停移动。训练主要是学习感知场景中正在发生什么，让这触发自发想象，并不加评判地信任它；有些具体技巧，比如“场景很早时就确立你在哪里”，但核心是培养激发自发想象并接受其产物的能力。
bkovitz查看英文原文
Stephenson's idea--generate high-quality stuff on the first run by cultivating your subconscious to spew only high-quality stuff--reminds me of performing improv. An improv scene is anything from a skit to an entire musical, performed without a script or planning. The players get on stage and just do it, by saying, acting out, and/or singing the first thing that comes to mind, one line at a time. There is plenty of bad improv: amateurish stuff, "gaggy" stuff (consciously aiming for cheap laughs), etc. But I've also seen amazing improv: entire plays and musicals, sometimes with serious themes, of such coherence and high quality that it doesn't seem possible that they could have been improvised. I once saw an entire Alfred Hitchcock "movie" improvised on stage, that somehow achieved Hitchcock's signature combination of eerieness and worldly elegance. I've spent about three years training in improv, and it's actually a lot like Stephenson's tale of needing to keep the typewriter ribbon moving. Training in improv is mostly learning ways to tune into what is happening in a scene, let that trigger your spontaneous imagination, and trust that without judging it. There are some very specific techniques, like "very early in the scene, establish where you are," but mostly it's developing that skill of stoking your spontaneous imagination and taking what it gives you. You know after a while when you're tuned in and when you're not. A non-obvious but important element is to go s-l-o-w (like Stephenson with the fountain pen). That enables you to tune in. If you don't have your imagination ready to go that way, cultivated by life experience and learning as well as by a feeling for how to tune into a scene, the good stuff just ain't going to happen. My own experience with writing code is something like improv. Sometimes it sucks, and sometimes it's wonderful. There's no way the good stuff could ever have come about by continuous distillation and debugging. It had to flow. I debug very little. If code is buggy, I just throw it away and start completely from scratch. When the code is flowing, nearly all of the "thinking" is subconscious. I'm just tuning in, as if someone else is writing the code. When it's going super-well, it feels like I'm taking dictation. Just like in an improv scene, I'm writing the current line because I'm curious to know what happens next.
修改不是修补初稿，而是明确目标后丢弃重写，并小步迭代。
有趣——从同样的数据我会得出不同结论。与其说“第一次就做对”，我会说“修改意味着重写。不要试图挽救垃圾”。我从来不能第一次做对，也从未成功把丑陋初稿变成漂亮代码。对我来说，修改是看看丑陋初稿想达成什么，扔掉它，第二次做对。这一切迭代进行，所以我从不扔掉完整作品，只扔掉最上面的最新部分。
nostrademons查看英文原文
Interesting - I would've drawn a different conclusion than Stephenson from the same data. Instead of "Do it right the first time," I would've said "Revising means rewriting. Don't try to salvage crap." I never get it right the first time. I also never succeed in turning that ugly first draft into pretty code. Instead, revising for me means taking a look at what I was trying to achieve with that ugly first draft, throwing it away, and doing it right the second time. All this done iteratively, so I'm never throwing out a complete body of work, only the latest bits on top.
写作需要先写一稿理清思路再从零写终稿；小说与编程不同，写作容忍模糊且可调整目标，不能简单类比。
我写作时也有同样经历：坏部分和好部分缠在一起，仅编辑不值得，我发现至少需要一稿来组织思路，然后从零写终稿，通常几乎不需要编辑。我的结论是我总需要写第二稿，而不是 Stephenson 的结论“第一次就写更好”。各人有各人的方法。但把写小说比作编程复杂系统至少很天真。第一个明显差异是：小说一般出自一个人头脑，大多数大项目太大，没人能真正全装在脑子里并理解所有交互。这几乎立刻使第一次就做对不可能；大项目中总有不理解或忘记的东西。还有小说容忍模糊且常常需要模糊，编程则不是选项；这意味着有更多细节要“做对”、更多决定、更多交互要担心。另外程序一般有确定目的，不能轻易根据实际行为重新定义目标；写作时你常知道方向或想要什么。
akeefer查看英文原文
I've had the same experience when writing, whereby my bad stuff was intertwined with my good stuff to the point where merely editing it was not worthwhile, and found that I need (at least) one draft to organize my thoughts before writing a final draft from scratch that generally needs very little editing. The conclusion I came to was that I just need to always write that second draft, rather than Stephenson's conclusion that he just needs to write the better draft the first time. To each his own, I guess . . . But comparing writing a novel to programming a complex system seems pretty naive, to say the least. The first obvious difference is that a novel (generally) comes out of one person's head, but most larger projects end up far too large for any one person to truly keep it all in their head and understand all the interactions. That immediately makes it pretty much impossible to just do things right the first time; there are always things you don't understand or forget about when working on a larger project. There's also the fact that vagueness is tolerated and often desired in a novel, whereas it's not an option when programming; that just means there are more details to "get right", more decisions to make, and more interactions to worry about. In addition, a program generally has a definite purpose, and you can't re-define your goal as easily based on what it actually does (though sometimes you can; when writing, you often have an idea of where you're going or what effect you want, but if you end up with something different it might still be fine. There are a ton of other differences as well, of course; those are just the ones that first come to mind.
同类还值得读
被低估的工程技能：把文章写好
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 条写作要点编辑精选