HN 写作课

工程师们二十年里聊过的写作。

工程师、作家、编辑和创业者在 Hacker News 上聊了二十年“怎么写”:怎么写得清楚、怎么讲好一个故事、技术文档怎么写、小说和出版是怎么回事。这里把其中关于写作与讲故事的帖子挑出来,配上中文导读、可以直接用的写作要点和评论翻译。

从必读开始
  • 2,600+篇关于写作的 HN 讨论

Writing tips

写作锦囊

正在抽一条写作要点…

Essential

必读 30 篇

在讨论库里看全部精选

编辑精选里 HN 讨论最热的 30 篇,每篇都有中文导读和写作要点。

  1. 正在载入…

Archive

讨论库

按发帖年份分布,点柱子筛选。

排序

    About

    这些讨论是怎么挑出来的

    1. 01

      从全量里捞

      读取 Hacker News 自 2006 年以来的全部帖子,用关键词先捞出 40 分以上、可能和写作有关的约 1.1 万篇。

    2. 02

      只留真正讲写作的

      由 AI 逐条判断是否和写作、讲故事、文风、出版有实质关系,剔除“写代码”“编辑器”这类字面撞车,并分进十个类别。

    3. 03

      提炼可用的要点

      为值得读的帖子写中文导读,提炼 2-4 条可以直接用到自己写作里的要点,并精选翻译 HN 高赞评论。内容由 AI 生成,可能有误。

    写作与思考2018medium.com

    你管理的不是软件工程师团队,而是一群写作者

    You’re Not Managing a Team of Software Engineers, You’re Managing Writers

    阅读原文 HN 讨论
    97HN 得分
    55条评论
    4条写作要点

    导读

    这篇帖子用「你管的不是工程师,而是一群作家」这个比喻,说明软件开发本质上是创造性、不可预测的工作,无法像流水线那样排期和度量。对写作者来说,它反过来提醒我们:写作和写代码一样,都是在一个不确定的环境里维持一套「活着的系统」;而且作家们积累了数百年的写作经验,值得跨行借鉴。

    关键词 写作与编程创意工作管理隐喻思维技术写作

    可以直接用的写作要点

    1. 01

      别用工时、速度(velocity)这类指标衡量创造性工作:写作的进展常常是「卡在某段研究上」,而不是线性推进。

    2. 02

      写文档时,要把文字当成系统的一部分:它的目标是让读者能长期维护、使用和理解,而不是自我表达的漂亮文本。

    3. 03

      把「作家们几百年的写作建议」当作素材库:它们比只有几十年历史的编程经验更成熟,通常也写得更好、更好笑。

    4. 04

      把「不知道该怎么写」当作写作的起点而非失败:动笔时本来就不该已经知道答案。

    HN 评论精选

    比喻失焦:产品是系统而非文本,写作只是工程师的一项技能。

    不,你管的就是一群软件工程师,写作只是他们的一项技能。产品不是那些文本,产品是一整套系统,用来让文本保持存活、可用、基本不出错,而且运行在相当不可预测的环境里。我们确实该学习其他行业如何管理不可预测的工作,但我不确定这个比喻适合这个目标。

    thinkingkong查看英文原文

    No youre managing a team of software engineers, one skill they have is writing. The product isnt the text. The product is the entire system designed to keep the text alive, functional, reasonably error free all in a relatively unpredictable environment. We definitely need to keep considering how other professions manage the unpredictable nature of their work so we can learn. Im just not sure this narrative suits that goal.

    写作传统比编程传统更久,作家的建议更值得借鉴,也更好读。

    Niven 写作第一定律:为其他作家写作的作家,应该去写书信。——拉里·尼文(1989)。「作家就是那个一开始动手就不知道自己要做什么的人。」——唐纳德·巴塞尔姆。作家建议的总结:作家的建议很有用,而且不只在命名上——他们干了几百年,编程才几十年;而且他们的建议写得更好,也更好笑。

    contingencies查看英文原文

    Niven's First Law of Writing: Writers who write for other writers should write letters. - Larry Niven, science fiction author (1989) The writer is that person who, embarking upon her task, does not know what to do. - Donald Barthelme Summary of advice from writers: Advice from writers is useful, and not only about naming. Writers have been at it for centuries; programming is merely decades old. Also, their advice is better written. And funnier. - Peter Hilton ... via http://github.com/globalcitizen/taoup

    讽刺用冲刺和速度指标管理创作,只会得到荒谬的对话。

    出版方(早上九点):该开晨会了……作者:昨天我写了几段,反派正要向主角透露他知道主角失散多年的兄弟。但我在越南战俘营的历史考据上卡住了,希望研究助手能尽快查清,这样我就能把这段从「受阻」栏挪回「进行中」。同时我把追捕场景那个「故事」拉了进来,但目前我认为这两个「故事」都要顺延到下一个冲刺。出版方:嗯,这会对你的速度指标造成负面影响。

    0x445442查看英文原文

    Publisher(9am): Time for the morning scrum... Author: Yesterday I worked on a few paragraphs where the antagonist was just about ready to reveal to the protagonist his knowledge of the protagonist's long lost brother. But I'm blocked on the historical research about Vietnam POW camps. Hopefully, if my research assistant can run that down soon I can move that paragraph from the unblocked column back to in progress. In the mean time I'm pulling in the foot chase scene "story" but at this time I think both these "stories" will carry over to next sprint. Publisher: Hmmm, that's going to negatively affect your velocity.

    管理者的价值在于扫清障碍,而不是替团队做具体创作。

    经理根本不该写代码或做架构。经理的职责是管人或管产品:管人就全力为工程师扫清障碍、把他们挡在会议之外;管产品就全力收集需求和约束、与客户沟通、向工程师要估算。架构和实现对经理来说是隐藏细节,应该由技术负责人、架构师或整个团队来设计和推进代码。

    ilovecaching查看英文原文

    Managers shouldn't be writing code or architecting at all. A manager's job is to manage people or a product. If it's people, she should be completely focused on unblocking the engineers and keeping them out of meetings. If it's the product, she should be completely focused on gathering the requirements and constraints and communicating with the customer and getting estimates from the engineers. The architecture and implementation is a hidden detail for a manager. Either the team lead, architect, or team as a whole should design and move on the code.

    同类还值得读

    1. 不要想好再写,要写来思考

      Don’t think to write, write to think

      这篇短文主张不要把写作当成思考完成后的记录,而要把写作本身当作思考的工具:动笔的过程会逼出想不清楚的地方。

      写作与思考2022 · 553 分 · 145 评4 条写作要点编辑精选
    2. 写作即思考:学会自信地写作

      Writing Is Thinking: Learning to Write with Confidence

      这是一篇讲“写作即思考”的博客:作者认为写作不是把想好的东西誊写出来,而是借助写作本身把想法想清楚,因此写作者应当建立信心、敢于先写烂稿。

      写作与思考2019 · 529 分 · 83 评4 条写作要点编辑精选
    3. 如何用写作来思考

      How to think in writing

      这篇文章讨论的是「用写作来思考」:作者认为写作不只是把想清楚的东西表达出来,更是想清楚本身的工具——文字落在纸上,你才有机会看见自己思路里的跳跃、含混和漏洞。

      写作与思考2024 · 424 分 · 120 评4 条写作要点编辑精选
    4. 写作,帮你逃离默认的人生设置

      Write to Escape Your Default Setting

      文章的核心主张就写在标题里:写作是帮你逃离「默认设置」的手段——日常的思维和表达都有惯性默认的默认模式,而落笔能逼你跳出来,重新看清自己到底在想什么、要说什么。

      写作与思考2025 · 407 分 · 93 评4 条写作要点编辑精选
    5. 写作就是思考

      Writing is thinking

      文章以“写作即思考”为题,讨论写作不只是把已有想法记录下来,而是帮助澄清、组织和推进思考的过程。

      写作与思考2025 · 330 分 · 128 评4 条写作要点编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。