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 生成,可能有误。

    出版与作家生涯2020aquicarattino.com编辑精选

    如何写一本编程书

    How to write a programming book

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

    导读

    这是一篇关于如何写编程书(技术书)的经验文章,配套的 HN 讨论把话题从“怎么写”扩展到“为谁写、以什么形式写”。值得写作者读,是因为评论者点出了技术写作中常见的失衡:内容过度迎合初学者、缺少可供练习的题目、出版形式本身也在变化,而这些判断同样适用于任何知识类写作。

    关键词 技术写作编程书读者定位练习设计

    可以直接用的写作要点

    1. 01

      写作前先明确读者层次,别让市场压力把全书都稀释成入门内容,要为有基础的读者保留进阶章节。

    2. 02

      把"帮读者过渡到能独立读代码/读原文"当作明确目标,而不是试图在书里讲完一切。

    3. 03

      每章配上有难度、附解答的动手练习,让读者从"点头认同"变成真正掌握。

    4. 04

      先以免费数字形式连载、收集反馈、边写边改,再考虑纸质版;并给每个小节标注写作、修订、测试的时间与版本。

    HN 评论精选

    技术书市场过度偏向入门,进阶读者被忽视。

    编程书让我不满的地方在于:市场压力让内容极度偏向入门,给进阶读者的材料少得可怜。看看电子学等其他领域,入门书就几本,专家级的细分专著却有一大堆。语言、范式、框架繁多确实是一部分原因,但我怀疑很大程度上是因为作者有强烈动机把书写得让纯新手也能读懂,否则项目基本注定失败。

    lmilcin查看英文原文

    What pains me about programming books is that due to the market pressure the balance is skewed extremely in the direction of beginner material and there is precious little material for advanced users. If you look at other branches of knowledge, say electronics, there is couple of books for beginners and then massive selection of highly specialized books for experts. I get that part of this is due to multitude of languages, paradigms, frameworks, etc. but I suspect that a huge part is due to the fact that programming book writers have huge incentive to make the book palatable to absolute beginners and anything else seems to be a sure way for the project to tank.

    先免费数字出版积累读者,再谈纸质书,并给内容标注版本时间。

    总的来说,书这种形式已经不太讲得通了。我看过一些知名技术书作者的财务记录:他们靠出书带来的产品、服务、咨询和演讲收入,远比卖书本身多得多。如果你喜欢写长篇技术指南,为了自己和读者好,想办法先免费数字发布、积累能直接互动的读者群,再让喜欢的人去买纸质版。这样写书就变简单了:养读者、给大纲、收反馈、继续写、写可测试的代码、再收反馈。你写的每一小节都应标注写作、重写、最近审阅、测试、环境测试的时间。

    billme查看英文原文

    Generally speaking, books as a format make no sense. I have seen the financial records for number of popular tech book authors — and numbers related to them having published, for example: products, services, consulting & speaker fees, etc. If the author is trying, they make way more money from the numbers related to them publishing than the book sales. If you like writing long form tech guides, do yourself and your audience a favor, figure out how to publish your materials for free digitally and grow an audience you have direct one-on-one access to, then allow people to order paper versions if that’s what they prefer. Then, writing a book becomes easy: grow audience, provide an outline, get feedback, write more, write testable code, get more feedback, etc. Anything you write (as in subsection) should have a timestamp of when it was: written, rewritten, last reviewed, test, environment tested, etc.

    编程书的首要目标应是帮读者过渡到直接读代码。

    我秋季可能要在线教线性代数,正在从零重想配套材料,而这篇文章并没有从零反思它的体裁,我差点没读下去。我学过几十种编程语言,越来越觉得编程书读不下去,它们给我一种真写代码反而能治好的"多动症"感。学自然语言也一样,没有单一方法奏效:阅读就只为提高阅读,听力就只为提高听力,在车里反复念句子当成一个自足的小游戏,然后相信这些分开的技能会在旅途中整合起来。就像围棋书会分门别类,专门讲短时段战术;学了几门语言后,你能轻松吸收一门语言的"短时段战术",却仍不知道如何地道地组装完整程序。正如最好的数学家只读原始文献,最好的程序员就是直接读代码。编程书可以缓解向读代码的过渡,我们应当明确这才是首要目标。

    Syzygies查看英文原文

    This is relevant to me because I'll likely be teaching Linear Algebra online in the Fall. I'm rethinking support materials from scratch. This article does not rethink its genre from scratch. And I nearly stopped reading, unwilling to take advice from a fixed pitch body font. I've learned dozens of programming languages, and I find programming books increasingly unreadable. They all give me that feeling of ADHD that actual programming heals. I've also made progress learning various human languages. No single approach works. Doing crosswords in old age doesn't fight off dementia but does make one better at doing crosswords. For language aquisition, read with the sole goal of getting better at reading. Listen with the sole goal of getting better at listening. Repeat phrases in the car as if that's a self-contained game one plays. Then trust that these separate skills will integrate as one travels; they do. For anyone who has learned the board game of Go, it's interesting how books on Go are compartmentalized. There are books solely dedicated to short timescale tactics, for example. After a few programming languages, one can easily absorb the "short timescale tactics" of a programming language, and still be at a loss on idiomatic ways to assemble complete programs. Just as the best mathematicans only read original literature, the best programmers simply read code. A programming book can ease the transition to reading code. We should be clear that this is our primary goal. One experiences a more intense sensation of comprehension, reading and understanding how a short complete program works, than reading any neverending text that ambles on. Take a cue from human language aquisition: Programming books should deliver a sequence of "aha!" moments of comprehension, teaching language constructs through explanations of a sequence of cleanly separated short complete programs. Their success should be measured in terms of the enjoyability and intensity of the experience of reading code this way. Leave it to the reader to find other ways to put together the rest.

    缺少附解答的难题,读者难以真正掌握。

    书里经常漏掉的一件事,是带解答的有挑战性的题目,让读者在真实例子里巩固新学的东西。跟着读、点头称是很容易,但没有那些记得住的动手例子,要把新技能真正用起来(至少对我来说)非常难。

    Vaslo查看英文原文

    One thing that is constantly left out of books is challenging problems with solutions for the user to cement the new ideas they’ve learned in actual examples. It’s very easy to read along and nod your head but it’s very hard (at least for me) to incorporate my new skills without memorable hands on examples.

    同类还值得读

    1. 写书:值得吗?

      Writing a book: is it worth it?

      Martin Kleppmann(《设计数据密集型应用》作者)复盘写书到底值不值:金钱回报低、耗时极长,但带来了可见度、信任和职业机会。

      出版与作家生涯2020 · 642 分 · 287 评4 条写作要点编辑精选
    2. 写书并不是个好主意

      Writing books is not really a good idea

      这篇文章讨论靠写书谋生的现实难度,评论区从版税数学、收入预期和写作目标三个角度补充了作者视角。

      出版与作家生涯2021 · 577 分 · 609 评4 条写作要点编辑精选
    3. 如何自助出版一本书:实用资源清单

      How to self-publish a book: A handy list of resources

      这是一份关于「如何自助出版一本书」的资源清单帖,涵盖从编辑、排版到 ISBN、销售渠道的实操工具与花费。

      出版与作家生涯2018 · 558 分 · 88 评4 条写作要点编辑精选
    4. 我自助出版一本Ruby on Rails书,赚了7万美元

      How I Made $70k Self-Publishing a Book about Ruby on Rails

      这是一篇 Ruby 开发者自述:他把一套 Rails 性能课程(书+视频+答疑)自出版,一年毛收入约 7 万美元,并总结了选题、定价、营销等经验。

      出版与作家生涯2017 · 539 分 · 175 评4 条写作要点编辑精选
    5. 石黑一雄警告年轻作家因“恐惧”而自我审查

      Sir Kazuo Ishiguro warns of young authors self-censoring out of 'fear'

      石黑一雄提醒年轻作者因“恐惧”而自我审查,即这条帖子讨论的核心。

      出版与作家生涯2021 · 396 分 · 641 评5 条写作要点编辑精选

    打赏支持

    打赏二维码

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

    WeChat

    关注向阳乔木

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

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

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