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

    博客与个人写作2010marco.org

    我为什么不写编程文章,以及为什么这并不值得

    Why I don't write about programming and why it's not really worthwhile to do so

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

    导读

    这篇帖子讨论作者为何不写编程题材、以及为什么觉得这类写作不太值得;评论区把话题扩展到评论机制、泛谈与具体实现、写作深度与读者面。对写作者来说,它有助于判断什么题材值得写、如何避免制造重复噪音,以及怎样处理公开后的反馈。

    关键词 技术博客写作选题信号与噪声评论区

    可以直接用的写作要点

    1. 01

      写具体问题和实现过程,而不是泛泛的“N 件事”清单;具体案例才有长期搜索价值和可读性。

    2. 02

      动笔前先确认自己的观点是否已被更好表达;若只是重复常见结论,就是增加噪声而非信号。

    3. 03

      多写“为什么这样做”和“哪些路没走”,这比只记录步骤更能沉淀可复用判断。

    4. 04

      公开写作要设计反馈边界:别让即时评论和碎片反馈打断深度工作,可先写私人日志、事后再公开。

    HN 评论精选

    把评论移到读者自己的平台会提高刻薄成本,但版主删帖又会面临“审查”指责。

    我认为网站不开放评论也挺好。想评论的人可以去自己的博客或 Twitter 上说;当他们写在自己的地盘而不是你的地盘时,会先想一想要不要刻薄:多数人不会为了发一条喷人评论而写整篇博客,而一个 Twitter 时间线全是恶言的人,除非非常机智,否则不会有很多粉丝。不幸的是,我网站虽没有评论,但作为论坛版主,这里的评论线程实际上让我照样收到评论。这种处境特别不愉快,某种程度比网站有评论区更糟:在自己网站上我可以删除恶评,但在这里删就会被指为审查。坦白说我无解;我偶尔想过封掉 paulgraham.com,但那样也会被指为审查。

    pg查看英文原文

    I think it's just as well not to allow comments on one's site. If someone wants to say something about something you've written, they can say it on their own blog or on Twitter. When it's something of theirs they're writing on instead of something of yours, they think twice before being jerks: most people won't create a whole blog post just to make a trollish comment, and someone whose Twitter stream is a series of nasty remarks is not going to have a lot of followers, unless he's very witty. Unfortunately, although I don't have comments on my site, as the moderator of a forum I get them de facto in the comments threads here. It's a uniquely unpleasant situation. In a way it's worse than having comments on my site. On my own site I could delete nasty comments, but here if I do I'll be accused of censorship. Frankly, I'm stumped. I've occasionally thought of banning paulgraham.com, but people would accuse me of censorship if I did that too.

    泛泛而谈的编程文章多是重复噪音,具体实现类文章才有长期价值。

    99% 的 Joel 式泛谈编程文章,都是对已有观点的无聊重复,而且往往前人(常常就是 Joel 自己)表达得更好。“每个创业公司都该知道的 10 件事”之类也一样:很适合在 HN 上赚 karma,但作为阅读材料很差。关于实际编程的博客,比如“我是如何实现 x 的”,几乎总是很好读;真正好的文章会长期保值,并随着出现在 Google 搜索结果中而触达博客读者之外的人。关键就是信号与噪声。你可能有一个好洞见,但如果 Joel、37 Signals、Coding Horror 等已经写过,你只是在增加噪声。

    nir查看英文原文

    %99 of the time, Joel-style posts about programming in general are a boring rehash of ideas already expressed better before (often by Joel himself). Same goes for "10 things every start up should know" etc. They're great for HN karma, poor as reading material. Blog posts about actual programming, as in "here's how I implemented x" are almost always a great read, and if they are really good they will sustain their value for a long time and reach far beyond the blog's readership as they start appearing in Google searches etc. It's all about signal vs noise. You may have a great insight, but if Joel/37 Signals/Coding Horror/etc already wrote about it you're just adding more noise.

    读者规模小反而会过滤评论者,不必把少数刻薄者当成整个圈子的常态。

    也许这取决于你还接触哪些受众,但我觉得编程博客圈没那么糟。确实有刻薄的人,可哪里都有。我的日常工作在学术界,学术会议上就有很多刻薄的人:你更容易遇到有人愤怒地觉得你侵入他的领域,或批评你没用他偏爱的方法、没引用他的论文,而不是遇到真心想理解你在做什么、为什么做的人。我偶尔把学术工作放到网上时,反倒觉得技术博客圈的反应更友好。当然,如果我是有大量读者的名人博主,情况可能更糟;读者较少时,通常只有一些有理由喜欢你作品的人才会费心评论。

    _delirium查看英文原文

    Maybe it's relative to what other audiences you also encounter, but I haven't found things too bad in the programming blogosphere. Sure, there are jerks, but there are jerks everywhere. My day-job is in academia, and there are a lot of jerks at academic conferences. You're more likely to get someone furious that you're intruding on their area, or critical that you aren't using their preferred methodology or citing their papers, than you are to get someone genuinely interested in understanding what you're doing and why. I actually sometimes find the tech-blog reception friendlier, on the occasions I've ventured some of my academic work online. Admittedly, it might be worse if I were a celebrity blogger with tons of readers; when only relatively few people read you, generally it's only people who have some reason to like your work that would bother commenting.

    有趣的编程问题难以压缩成短文,公开写作的碎片反馈会分心;先写私人日志,多写“为什么”和未选路径。

    我不写编程博客有别的理由:任何真正有趣的编程问题都太复杂,没法压缩成别人在十分钟博客休息里能消化的散文。我可以写第 N 个数独求解器,或写我解决的某个棘手 Haskell 问题;但如果它泛到能让广泛读者感兴趣,就太浅,无法给人启发;如果它深到真正有用,又往往太具体,不会有广泛感兴趣的读者。更糟的是,我觉得参与博客圈会让我误以为这些信息碎片有价值,用琐碎的小知识占据注意力,妨碍我做真正有趣的工作。我认为写编程的价值在“为什么”和“未走的路”。所以我为个人项目保持一份开发日志,至少能防止自己重新纠结已经决定的设计。但这不必公开也能起作用;我发现公开它太分心,会妨碍项目继续推进。我改为等项目成功或失败后再开放,比如我写的《失败创业公司日记》,希望我开发中的编程语言也能这样。这不是持续、即时反馈带来的自我满足——但那种自我满足会变成一种药物……

    nostrademons查看英文原文

    I don't blog about programming for different reasons... I find that any really interesting programming problem is too complex to be reduced to prose in a form digestible in someone's 10-minute blog break. Yeah, I could post about the umpteenth-zillion Sudoku solver, or about this tricky Haskell problem I solved - but if it's general enough to be broadly interesting, it's too shallow to be enlightening, and if it's deep enough to be useful, it's probably too specific to have a widely interested readership. Worse, I feel that by participating in the blogosphere, I'm deluding myself into thinking that these information soundbites are worth anything, and taking up my attention with little factoids that distract me from getting actually interesting work done. I find that the value of writing about programming is in the "Why?" and the "Roads not taken" of software systems. So I keep a development journal of my personal projects. At the very least, it keeps me from revisiting design decisions I've already decided. But this doesn't need to be public to serve its purpose, and I've found that making it public anyway is too distracting to maintain forward momentum on the projects. Instead, I open things up after the project has succeeded or failed, like I did with Diary of a Failed Startup and like I'll hopefully do with this programming language I'm developing. No, it's not the ego boost that constant, instantaneous feedback gives you - but that ego boost becomes a drug that keeps you from functioning when people (as the article points out) turn on you, as they inevitably do.

    同类还值得读

    1. 我坚持每天写一条 TIL,已经写了一年

      Show HN: I've been writing daily TILs for a year

      这篇展示作者一年每天写 TIL(Today I Learned)并整理到 GitHub 仓库的做法。

      博客与个人写作2016 · 819 分 · 150 评4 条写作要点编辑精选
    2. 如何写出开发者愿意读的博客文章

      How to write blog posts that developers read

      这篇(正文与评论未提供,仅从标题判断)讨论面向开发者写技术博客的方法:怎样让忙碌的工程读者愿意点开、读下去并读到结尾。

      博客与个人写作2025 · 603 分 · 154 评4 条写作要点编辑精选
    3. 博客写作风格指南

      A blogging style guide

      这是程序员兼博主 Robert Heaton 的博客写作风格指南,用几十条简短规则讲如何让技术文章更清晰、更好读。

      博客与个人写作2018 · 495 分 · 188 评4 条写作要点编辑精选
    4. 十年职业博客写作,我学到了什么

      Ten years of professional blogging – what I’ve learned

      这是作者回顾十年专业博客写作经验的总结,评论补充了写作作为深度学习、聚焦主题、保护写作习惯和选择发布平台等实践。

      博客与个人写作2017 · 362 分 · 126 评4 条写作要点编辑精选
    5. 十年博客写作教给我的事

      What I learned in ten years of blogging

      这是一篇博客作者十年写作经验总结,核心观点是写作的价值在于持续积累而非单篇爆款。

      博客与个人写作2018 · 356 分 · 162 评4 条写作要点编辑精选

    打赏支持

    打赏二维码

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

    WeChat

    关注向阳乔木

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

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

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