本文将是短期内 Grow at Google 系列的最后一篇文章，可能也会是近期以软件工程师的自我成长作为话题的最后一篇。
在《Noogler 成长的必经之痛》、《「能用就行」还远远不够》、《「程序员」和「软件工程师」是一回事吗？》这三篇文章中，笔者围绕「如何成为一个更好的软件工程师1」谈了不少话题。包括这些文章在内，本博客绝大部分文章的创作灵感都来自于笔者在学习工作中收获的经验和教训。而随着工作的逐渐稳定，笔者自身的成长速度已经跟不上理想的博客更新速度了。笔者在目前能言之有物的内容，基本都已经分享过了。其中一些核心的老生常谈话题也已经反复出现，比如缩短 Feedback Loop 等。
简而言之，过去那种写博客的思路已经无以为继了。在这篇较为简短的文章之后，笔者将开始尝试把写作重心转移到专注某个单一话题的文章上。话题也会逐渐多样化，包括许多技术之外的内容。敬请期待。
这里所说的文档指的不是 API / 库 / 框架的文档（documentation），而是最普遍意义上的文档（document）。以 Google 为例，我们在工作中大量使用 Google Docs 进行沟通和协作。在开始一个新项目时，产品经理们经常要写 Product Requirements Document (PRD)，而工程师们则要写 Design Doc (DD)2。有时我们也会针对更小的话题写一些 One-pager（实际并不一定只有一页）。
当然，具体采取什么形式和使用哪种工具是次要的。笔者在这里想要呼吁的是：在条件合适的前提下，希望有更多的工程师能够具备使用文档进行沟通和协作的意识和能力。
- 协同编辑和异步沟通都是非常基础、永远会有适用场景的工作模式。而文档则是最简单、最直观的一类能够支持协同编辑的异步沟通方式。
- 话题的复杂度越高，参与对话的人数越多，即时聊天/视频会议/电子邮件等形式的效果就越差。文档能够起到很好的替代或是补充作用。
- 写作是很好的整理思路和检验理解的方式。写作迫使我们去思考，去把已知的信息用便于沟通的方式呈现出来，把所有「显然」的细节都展开阐述。在这个过程中，我们往往会发现在写文档前没有考虑到的问题，或是发现自己的理解有欠缺的地方。
- 文档的可追溯性更好。在技术讨论这种相对较为纯粹的环境下，通过减少「我原本打算这样，但……」和「他告诉我那里应该这么做」这样的私下沟通，所有的对话参与者都能更容易地确认他人的想法，从而明确大家的共识和矛盾分别在哪里。与此同时，一份满载对话的文档也是很棒的新人学习材料，对进行自我回顾和反思也很有价值。
- 在可以预见的未来，分布式工作会更为流行。高效地通过文档进行协同工作将成为一门必备技能。
- 有时我们可以写文档也可以不写，有时我们则不得不写文档，而后者往往是在更为严肃、重要的场合下。所以在平时就锻炼文档意识和能力，对职业发展有着长远的好处。
从半年前开始，笔者承担起了 mentor 刚加入我们团队的新人的责任。总的来说，这是一种不错的体验 manager 的部分职责的方式。笔者在这个过程中积攒了一些心得：
- 新人在最初是大概率无法独立完成工作的。视能力不同，有时作为 mentor 还会不得不「手把手」地教新人做事。当需要学习的内容很多时，新人很容易怯于寻求帮助。这时候一定程度的 micro-manage 是有益的。我们应该相信新人的可塑性和学习能力，通过定期 sync、主动询问和亲自示范来让新人快速上手。
- 由于 Curse of Knowledge3，我们总会对新人吸收知识的速度有过高的期望。不要指望新人能够将被传授的东西记下全部或者绝大部分。很多时候，让新人写文档是很好的检验对方在哪方面的理解还有所不足的方式。
- 通过在回答新人问题和讲解任务需求时有意识地留白，锻炼新人独立思考和学习新事物的能力。
与此同时，笔者也体会到了培养新人的一系列益处。希望有更多的工程师能够愿意花费时间按和精力去培养新人。
- 个人的成功往往跟团队的成功紧密相关。新人上手得越快，整个团队的生产力就越高。
- 新人在工作中的思维方式尚未「固化」，往往能发现一些团队里的大家已经习以为常但其实有很大改进空间的地方。类似地，新人提出的一些问题还有可能暴露我们的知识盲区。
- 新人通常是合理的零碎任务下发对象。只要能够在任务的挑选上多留心眼，新人可以通过一系列不那么 overwhelming 的任务去加深对团队和系统的理解，而我们则得以将更多的精力集中在更符合自身能力的任务上。
- 在项目规划中避免过长的估计4。类似「这个功能要做两周」或是「这个项目需要三个月」这样的估计，往往是我们没有把关键的点都思考和理解清楚的信号。时间越长，中间就越可能出现意外。
- 限制 work in progress 的量。在对工作较为熟悉、multitask 和 context switch 能力得到一定锻炼以后，许多工程师会倾向于同时承担多个项目。而经验告诉我们，一个项目 launch 之前的 last mile 是最容易出现意外、延迟和额外工作量的。如果同时进行多个项目，每个项目的 overhead 很容易堆积起来，创造大量本可以避免的工作。所以，有时与其多启动一个项目，不如加快把将要 launch 的项目收尾。
- 进步最快的方式：读没读过的代码，写没写过的语言，用没用过的工具。
- 笔者观察到有很多工程师在工作上不够自信，不能清楚明确地向 manager 表达诉求，或是不擅向他人寻求帮助。要想在职业道路上走得更远，这些是我们每一个人都需要克服的障碍。
- 严格来说这里需要加上「大公司」和「北美职场」这两个限定条件。在一些其他环境下，笔者的部分心得可能是不太适用甚至有害的。之后或许会谈谈这种割裂的现象。
- 关于 Google 内部使用的 Design Doc，可以参考这里的介绍，以及 Hacker News 上对其优劣和适用场景等的讨论。
- https://en.wikipedia.org/wiki/Curse_of_knowledge
- 当然，这里指的是工程上诚实的估计。由于种种原因而刻意夸大的时间估计不在讨论范围之内。