写作与思考2022founder-fodder.ghost.io
在有写作文化的公司工作，我最喜欢的几件事
My favorite things about working at companies with a culture of writing
导读
作者在一家有写作文化的公司工作，总结了自己喜欢的几点：写下来能逼你想清楚、文档让决策可追溯、异步沟通减少会议、写作让远距离同事也能贡献想法。对写作者来说，这是一份"把写作当成工作方法"的实战观察，而高赞评论提供了必要的反面：写作文化容易变成文档表演、知识库腐烂，还会惩罚非母语写作者。
可以直接用的写作要点
- 01
把写作当成思考工具而不是交付物：先写一页纸把问题想清楚，再决定要不要开会或动手。
- 02
不是所有问题都值得写长文档，按影响范围和不可逆程度决定投入多少笔墨，否则写作会吞掉真正干活的时间。
- 03
写完只是开始：给文档建索引、标负责人和更新日期，否则知识库会腐烂，读者还是回去靠私聊和口口相传。
- 04
照顾非母语读者和写作者：少用炫技的长句和内部黑话，让文字对语言能力不占优势的同事也友好。
HN 评论精选
写作文化过度执行会变成文档表演，反而挤掉真正的工作，并压制异议。
我在一家人人都知道的公司工作，那里以"人人都写、人人都读"自豪。但作为一线工程师，我大部分时间都陷在文档里：每做一个小决定都要产出一大堆文字等人评审，我已经三周没写代码了。不是每个问题都值得写一页纸，不是每个改动都要先有一份同行评审的设计文档，也不是每种失败可能都要把血淋淋的假设细节写出来。而且你不敢抗议——一抗议就会被贴上"不合群""沟通差""独狼"的标签，绩效被评为不合格，最后被"优化"掉。绩效季更是文学版饥饿游戏：大家写文档公开夸自己一年的工作。这套机器对"语气"还特别敏感，你不同意某人的文字，他就觉得是人身攻击。
ekfNsPsoQp查看英文原文
I work at a company you’ve all heard of that prides itself as a place where everyone writes and everyone reads. A lot. I’m an individual contributor. In theory, my job is to build stuff, which - again, in theory - involves writing code, debugging, solving deep technical problems, and so on. Unfortunately, due to the culture of writing and reading I spend most of my time mired in documents. Every breath we take produces a wall of text that must be reviewed and commented on. At this point it’s been about three weeks since I’ve written code. Not every question deserves the dreaded one-pager. Not every potential code change must be foreshadowed by an exhaustive treatment in a peer reviewed design doc. Not every potential failure mode must be imagined and written up in detail, including all hypothetical gory details. And don’t you dare protest! You’ll be labeled not a team player, poor communicator, a lone wolf. You’ll get a negative performance rating in the next cycle and then “managed out” for non-compliance with prevailing culture. Oh, performance reviews are a special kind of joy. For a few weeks each year the economy of writing traffics mostly in documents written by employees who must openly brag about work they did over the past year. It’s a kind of literary hunger games in a corporate setting. Oh, and this Kafkaesque machine has feelings too. It’s weird about “tone”: disagree with someone’s writing and they see a personal attack. Sickly sweet praise is the name of the game, whereas legitimate critique of another’s writing must be circumspect and formed such that it cannot be “taken the wrong way” or else! I’m so done.
没有阅读和检索习惯配套，写得再好也没人看。
反面观点：这套东西只有在公司先有"读"的文化时才成立。我花了很多时间写一份详尽的 README，但大多数人最多扫一眼，然后照旧问问题、照旧犯我犯过的错。写作本身没问题，但你得有配套体系：索引、目录，以及一种"告诉别人去哪找什么"的习惯。
Cthulhu_查看英文原文
Counterpoint: this can only work if your company has a culture of reading first. I spent a lot of time on an exhaustive readme, but at best people skim it and ask questions or make the same mistakes I made again. Writing is cool and all, but make sure you have a system in place, an index, and a culture of telling people where to find what.
文档会腐烂；让代码和配置文件自解释，比堆知识库更可靠。
反面观点：Confluence 本身是好工具，但光听到名字我眼睛就翻得发疼。我参与过的项目里，所谓"知识库"往往长成一堆庞大又无可救药地过时的文字垃圾。很少有人读别人写的东西，更少有人去修正或更新，找点东西得在重复的搜索结果里翻来翻去。我不敢说整洁代码能解决一切，但自解释的代码确实省时间：少写文档、少维护文档、读代码也更容易。更偏元信息的东西可以用注释或基础设施文件表达，最终还有 README.md。很多时候看 package.json 或 docker-compose.yml，比看 Confluence 更管用，甚至是看懂它的前提。
woodpanel查看英文原文
Counterpoint: Confluence, by itself a great tool, just by hearing its name is making my eyes hurt from all the rolling. I can't count the projects I took part in, in which the "knowledge database" had grown in to a gigantic, helplessly out-dated pile of words. Few people read another persons content, thus even less correct/update it. Finding anything usually involves scrolling through redundant search results and entries. I know clean-code can't solve everything but I find self-explanatory code to be a major time-saver: less need to write documentation, less need to update documentation, easier getting an understanding of the code. For everything more meta, there are still comments or e.g. infrastructure files. And ultimately the README.md. Looking into a package.json or docker-compose.yml often was more helpful if not a requirement to make sense of Confluence's content at all.
写作文化要解决知识归档问题，也要警惕用文笔好坏误判人的能力。
我基本同意文章的每一点，但好奇大家怎么处理两件事：一是知识组织。我常看到写得很好、初衷也好的资料被扔进共享网盘或 wiki 里烂掉、过时，同一主题出现多份甚至互相矛盾的文件，想找的东西很难找，最后大家又退回到口口相传和私聊问人。二是写作文化会惩罚并打击非母语者——他们的写作水平可能不如同事，但能力很强。我共事过非常聪明的人，只因为语言不够漂亮，就被当成"笨"。
itsronenh查看英文原文
I agree with most, if not all, the points raised in the post. I'm curious how people deal with: 1. Organizing knowledge. Too often I've seen a lot of well-written and well-intended information thrown into a shared cloud drive or wiki to rot and grow stale. You end up with multiple, sometimes contradicting documents about the same topic, finding what you're looking for is difficult, and before you know it people revert to tribal knowledge and slack DMs to find out what they need. 2. A writing culture can penalize and demoralize non-native speakers whose writing skills may not be as strong as their peers. I've worked with brilliant individuals who felt like they're perceived as "stupid" because their language skills weren't as polished.
同类还值得读
不要想好再写，要写来思考
Don’t think to write, write to think
这篇短文主张不要把写作当成思考完成后的记录，而要把写作本身当作思考的工具：动笔的过程会逼出想不清楚的地方。
写作与思考2022 · 553 分 · 145 评4 条写作要点编辑精选写作即思考：学会自信地写作
Writing Is Thinking: Learning to Write with Confidence
这是一篇讲“写作即思考”的博客：作者认为写作不是把想好的东西誊写出来，而是借助写作本身把想法想清楚，因此写作者应当建立信心、敢于先写烂稿。
写作与思考2019 · 529 分 · 83 评4 条写作要点编辑精选如何用写作来思考
How to think in writing
这篇文章讨论的是「用写作来思考」：作者认为写作不只是把想清楚的东西表达出来，更是想清楚本身的工具——文字落在纸上，你才有机会看见自己思路里的跳跃、含混和漏洞。
写作与思考2024 · 424 分 · 120 评4 条写作要点编辑精选写作，帮你逃离默认的人生设置
Write to Escape Your Default Setting
文章的核心主张就写在标题里：写作是帮你逃离「默认设置」的手段——日常的思维和表达都有惯性默认的默认模式，而落笔能逼你跳出来，重新看清自己到底在想什么、要说什么。
写作与思考2025 · 407 分 · 93 评4 条写作要点编辑精选写作就是思考
Writing is thinking
文章以“写作即思考”为题，讨论写作不只是把已有想法记录下来，而是帮助澄清、组织和推进思考的过程。
写作与思考2025 · 330 分 · 128 评4 条写作要点编辑精选