软件工程师应该多写文章

小学时，老师会把孩子分成”数学好的”和”语文好的”。后来我成了”数学孩子”，顺理成章报了计算机专业，打算当一名软件工程师。可我发现，那条”理科生 / 文科生”的沟壑并没有消失，反而越拉越深——今天的工程师普遍畏惧写文章，而会写文章的人看到代码往往就晕了。

真心可惜。

没错，软件工程师当然要会写代码。但我们也应该去写点文章。

一、最好的工程师，也是好的写作者

软件工程师该写文章，最根本的原因是：写作锻炼的能力，和编程需要的核心能力是同一项——清晰思考的能力。

最好的软件工程师也是伟大的作家，因为他们的散文会像代码一样逻辑分明、优雅整洁。

这不是比喻，是事实。写文章逼你把脑子里的混沌理清、按逻辑铺开；写代码同样逼你先把问题拆解清楚，再用精确的语言表达。两者都是”把模糊想法变成精确结构”的练习，底层肌肉是同一块。

二、代码和文章，本就是亲兄弟

很多人以为写代码和写文章是两码事，其实它们像得惊人：

文章的大纲，就是软件的架构。 一篇没有大纲的文章会散，一个没有架构的软件会崩——本质一模一样。当你学会用文字把一件事讲清楚，写代码时的”结构感”往往会同步变强。

三、工程师和作家，连”痛苦”都一样

越临近截止期限，工程师会和作家一样焦躁不安。

更巧的是：就像文章永远可以精益求精，我们也永远不能说软件已经彻底”done”了。 这种”还能更好”的执念，让工程师总想再加个功能、再重构一遍模块，也让他们常常担心自己没做到最好。

这种对”完成度”的焦虑，写作者再熟悉不过。所以别再说”我不适合写东西”——你写代码时那份较真，和作家面对稿子时一模一样。

四、协作时代，书面表达是硬通货

现在的项目越来越离不开合作：开源项目邀请世界各地的人参与，产品开发需要众多工程师通力协作。比如谷歌地图，背后有 1100 名全职员工。

在这种规模下，清晰的书面表达能力无处不在：

• 写 GitHub 评论、做 代码审查，话讲不清就扯皮；
• 写 技术文档，文档烂项目就难接手；
• 哪怕只是提个 Issue，表达准确都能省下无数来回。

清晰、简洁的沟通，始终是推动这类项目前进的润滑剂。

五、写作是学习的杠杆

即便是一个人闷头做的项目，写点东西也大多能促进学习和讨论。

想想看：多亏别的工程师写了教程，我们才不必去硬啃那些让人头大的 RFC 规范和技术手册。一篇好的技术文章，能顶你翻三天文档。写得特别好的，会被顶到《Hacker News》、被转上 Twitter；其余的，也会沉淀成一篇篇博客，继续帮到后来人。

也就是说，你写的每一篇，都是在给”未来的自己”和”陌生的同行”省时间。

六、写博客，急不得

顺带说一句，写博客文章也是要投入时间的——和好文章一样，先有初稿，再靠一次次修改把质量磨上去。别指望一下笔就完美，改，才是写作的常态。这点也和重构代码异曲同工。

七、你可能本来就喜欢写

软件工程师之所以该试试写作，还有一个被忽略的原因：我们其实可能是喜欢写作的。

从小到大，我们不停地被灌输”我们文科不行”这种念头，于是大多数人从没想过自己还有写作的潜力。打破这个自我设限，会不会让你突然来了兴趣、有了干劲？

写作不仅会正面影响你的职业规划——管理类博客能帮经理鼓舞团队、推动积极性；编程教程能点燃学生对计算机科学的兴趣；一些职业建议甚至能激励毕业生走上全新的道路。

八、哪怕没人读，也值

退一万步说，即使根本没人读你的文章，也没关系。写作这个过程本身就让你受益匪浅：

• 它训练你把某个主题清晰阐述出来的能力；
• 把脑中杂乱无章的念头，一步步变成具体言辞的过程，本身就极有价值。

写作还会反过来影响你编写软件的激情。当它和有用的软件技能结合、和协作结合，你会突然发现：写作已然成了一项非常有价值的活动。

九、给工程师的写作起步建议

如果你被说动了，但不知道从哪下笔，给几条低门槛的：

1. 从”教别人”开始：把你刚搞懂的一个知识点写成教程，假想读者是三个月前的自己。
2. 复用工作产出：解决了一个棘手 bug？把排查过程记下来，就是一篇好文。
3. 先完成再完美：像写代码先跑通再优化一样，文章先出初稿再改。
4. 固定一个小习惯：每周一篇 500 字的技术笔记，比一年憋一篇长文更可持续。
5. 发出来：放到博客、公众号或技术社区，反馈会逼你写得更好。

十、写在最后

写作带来的那种”把想法理清、再表达出来”的爽感，和编写软件时的成就感如出一辙。把它和软件技能结合起来，用于协作、用于学习，写作就会从”文科生的活儿”变成你手里的另一件利器。

哪怕是对于那些自认的”数学孩子”，也一样。

所以，下次写完一段漂亮的代码，不妨也写一段漂亮的文字——它们，本来就是亲兄弟。