Software Engineering at Google - 阻碍工程师成长的几种想法
前言
从 2022 年 10 月中旬开始到 12 月中旬，日拱一卒，终于把「Software Engineering at Google」通读了一遍。书中介绍的是每个软件公司都会遇到的问题：如何培养好的工程师文化？如何共享知识？如何组建和带领工程师团队？如何长期维持软件质量？等等。同样的问题，在不同的规模、时间范围下的挑战不同，思考角度、解决方案、落地周期也都不同。这本书介绍的正是这家拥有超过两万名工程师的软件公司在这些问题上的思考。
在过去的工作经历中，我作为新人、下属、导师与不同类型的工程师有过不同程度的合作，他们之中既有顶尖的工程师，也有敬业的技术经理；既有人菜瘾大的码农、也有性格孤僻的极客；既有刚毕业就躺平的新人、也有工作十多年依然精力充沛的老兵。在这些合作经历中，我最大的感触就是：一名优秀的工程师，在技术层面外，还得是半个心理学家，既要熟练控制计算机、也要擅长与人合作。书中多处阐述工程师容易陷入的思想误区，它们或多或少地会阻碍工程师们成长，我也是其中之一。今天恰好借着看完这本书的契机将关于它们的思考记录下来。
正文
一个人写代码是编程，一群人写代码是软件工程。有一些思想，在个人编程时不会出来作妖，但进入软件工程中就会限制个人在团队中成长。如果不是关系很亲近、心态很开放的朋友或同事，没有人会主动指出这些思想的危害。这是一种「unknown unknown」，即当事人并不知道这些问题的存在，也就无从改进。
注：本文不是一次穷举，而是是将我遇到过的这些思想，结合书中的表达做一次枚举。如果有新的想法，我会持续更新到这篇文章中，勉励自己，也期待能帮助更多渴望在团队中成长的工程师。
想要一次性开发出完美的作品
可能是担心别人看到有缺陷的代码嘲笑自己；可能是觉得自己的想法尚未完全实施，还有一些细节可以优化；也可能是觉得当前的实现并不完美，还想独自再探索探索……出于种种原因，许多工程师都会有「一次性开发出完美的作品」的冲动，结果却很骨感。因为想做出完美的作品，提到仓库上的是成百上千行的改动，增加审查的难度；因为想做出完美的作品，过早地将时间花在还未出现瓶颈的优化点上，一旦方案改变，这些优化都将付之东流；因为想做出完美的作品，尽管十分努力研究，但囿于个人的知识储备和经验，花出去时间却无法找到满意解。
早点展示自己的作品，无论是将代码提到仓库，将设计文档发到评审会议群，还是将功能暴露给用户；不做过早的优化，将时间更多地花在验证主体思路，实施核心路径上；放弃英雄主义心态，融合其他人的经验和思想，扩充解空间的维度。这些方法都能帮助我们及时发现并解决问题，使风险左移，让之后的每一步都走得更踏实、更有信心。
现实中并不存在完美的作品，用户会变，环境会变，开发团队会变。尽管变化会影响当前方案的有效性，但变化才是真正的常态。
写文档是不务正业
不论是会议纪要、技术评审还是产品使用文档，都是与外界沟通的桥梁。好的文档，不仅可以记录产品迭代的历史与现状、加快他人理解产品的速度、减少不必要的答疑，还可以展现团队的专业能力、提升口碑、收集有价值的反馈、获取新的见解、甚至吸引感兴趣的人参与共建。
工程师最大的愿望就是辛苦撰写的代码能上线、有人用、有反馈。如果能进一步迭代，吸引更多的用户，遇到更复杂的问题，接着找到解决方案并落地，更好。从这个角度出发，文档实际上是这个过程的催化剂。
陷入「写文档是不务正业」这种想法误区的人，要么是没有认清文档的价值，要么是在逃避做自己不擅长的事情。没有认清文档价值的工程师大体会认为写文档就是浪费时间，有这时间不如研究更新的技术活框架，把代码写得更好；逃避写文档的工程师在一定程度上认同文档的价值，只是不想写或者把它的优先级设得很低，只有百无聊赖的时候才会动这个念头。
写文档和写代码一样，都是语言表达，都是需要实践才能获取的技能。写得多，文思泉涌，写得少，提笔忘字。
应该在团队里无可替代
有这么一种想法：如果有一件事情，全公司只有我能做，离开我谁也做不成，我在团队中就会变得无可替代，并且我应该持续积累这种「竞争优势」，不断提升这种不可替代性从而立于不败之地。这是封闭心态的一种典型案例。在过往的经历中，我曾多次遇到持有类似想法的同事。
持有这种想法，对于工程师，会在无形中屏蔽自己与外部的信息交换通道，同时这些事情的积累也会让他在工作中疲于应付，挤占宝贵的时间，无法抽身去解决其它问题。信息交流和可支配时间的减少都会阻碍个人成长；对于团队，这位工程师就是一个故障单点，没有备份，整个团队的可靠性就会因此被削弱。同时，团队内部也会因此形成信息孤岛，如果所有成员都各自负责自己的一亩三分地，团队也会失去存在的意义。
从自身出发思考
「从自身出发思考」本身是中性的，它并不意味着持有这种想法的人很自我或很自私，而只是一种思考惯性。比如招聘的时候倾向于寻找和自己相似的候选人；开发产品时把自己当做是典型用户，按自己的需求设计；和产品经理沟通时过度地从实现层面否定设计方案。
招聘更多和自己相似的候选人，会让团队的多样性下降；开发时以自己为典型用户，容易做出无人问津的产品；和产品经理沟通时过度地以实现难来反驳，离开了问题的本质，违背了第一性原理。
因为我们最了解自己，将自己带入其中思考最简单易行，要从其他人的角度出发思考，反而需要付出额外的努力。但当我们发现走出自己熟悉的范围，从他人身上汲取经验，能最终促进结果向更好的方向发展时，就会认识到这份努力的价值。
把组员当小孩
成为项目的负责人是一件令人振奋的事情，终于有机会崭露头角。但负责一个项目的交付并不是一场独角戏，而是团队合作的舞台剧。
项目负责人的风格大体可以有两种：「把组员当小孩」和「把组员当成年人」。工作拆分上，前者倾向按任务拆，后者倾向按问题拆；工作分配上，前者倾向于把有挑战性的部分留给自己，后者倾向于分给组员；工作跟进上，前者倾向于多开会，多确认，事无巨细，后者倾向于少开会，跟进关键节点，抓大放小。这两种风格在目标达成的效率上没有绝对的好坏，哪种风格效率高取决于团队成员中「小孩」和「成年人」的比例。但是从团队的成长性上看，后者显著优于前者。「把组员当小孩」，负责人很累，组员感受不到信任，技术上难有收获，唯一的收获是完成任务；「把组员当成年人」，负责人有更多的精力做规划，组员有发挥空间，在完成任务的同时每个人都能有收获。
尾声
成长过程中最困难的是改变自己的思考惯性。减轻这些思考的重量，让它们变得轻盈，可以帮助我们减小思考惯性，提升我们的可塑性。即便明白这些道理，有时候我们依然会在工作中陷入其中。通过刻意练习和及时反思，虽不能保证我们与这些想法绝缘，但至少可以降低陷入误区的频率。