毋庸置疑，工程师在互联网科技的历史上扮演着极其重要的角色，如创立微软的程序员比尔·盖茨、依靠搜索算法创建 Google 的佩奇和布林、构建 Facebook 社交网络的黑客马克·扎克伯格，无数大名鼎鼎互联网公司都是由工程师所创立。

对于技术人员来说，到底有没有自己特定的文化？什么才是真正的工程师文化？

今天，我想在这里再谈一下工程师文化，一方面是因为我又有了一些想法和体会；另一方面，因为我也正走在创业的路上。

我认为，建立一个有浓重的工程师文化的团队或公司，有必要把自己的想法形成白底黑字的“字据”，以供以后打自己的脸：

“要是未来没有做到，这篇文章就打我未来的脸” 或者 “这篇文章太幼稚了，未来的我会打我现在的脸”。当然，如果非要打脸，我希望是前者。

为什么要工程师文化？

看看最近二十年来社会的发展，计算机和互联网已经渗透到了这个社会的每一个角落，各式各样的计算机技术成为了整个世界发展的强大引擎。

无论是业务创新还是技术创新，都依托于技术的快速演进，技术成了解放生产力、提高社会运作效率的中坚力量。

今天，每个从事计算机行业的技术人员都应该感到幸运，因为，我们不但选对了行业，也出生在了正确的时代，可以感受到前所未有的刺激和变化。

此时我们只需要思考一个问题，那就是，我们是否处在正确的地方并用正确的方式做事？

在我看来，这个世界上有三种类型的商业公司：

运营或销售驱动型公司

这类的公司以运营和营销见长，技术对于它们来说更多的只是为了支持大规模的营销活动，以及成本上的控制，所以，基本上来说不太需要技术创新。这类公司非常缺乏安全感。

产品驱动型公司

这类公司以产品见长，创造能提升用户生活体验的产品，技术对于它们来说，除了支持大规模的在线用户之外，更重要的是增强用户体验，提高整个业务流程效率的技术创新，比如在 UI 交互和业务流程方面。

这类公司最大的问题，就是容易被别人模仿和抄袭。

技术驱动型公司

这类的公司相信技术能改变世界，它们更多的是用强大的工程技术来创造颠覆性的产品，用各种自动化的技术取代人类工作。

比如：近代蒸汽机技术取代了大量的人工劳动，数字技术取代了大量信息传递的人工劳动，未来它们还希望通过人工智能来代替人类做更多的决定。这类公司最大的问题就是可能做出叫好不叫座的产品。

这三种公司都可能成功，也都有问题，但是，无一例外，他们都需要强大的技术支撑，只不过，他们把技术所放在的位置不一样。

无论你有多么的看不起技术人员，你都无法否认，你今天的生活相当的依赖这帮工程师，没有他们，你恐怕都不知道怎么生活了。

邓爷爷几十年前就说过——“科学技术是第一生产力” ，无论什么样的科学技术的理论要落地都会依赖于工程技术有多先进。

所以，在今天，作为一个 IT 或互联网公司，“工程师文化”不是一个问题，而是一个常识！

工程师文化的“两大法宝”

简单来说，我把这么多的工程师文化总结成两大类：“自由” 和 “效率”。

本来还应该有个“创新”，但我个人认为，创新的前提是——在自由的环境下对提高效率的痴迷，就一定会发生创新。

创新不是凭空出现新的东西，其实，观察一下人类的发展史不难发现，几乎所有的创新基本上是“跳出原来的思维模式用新的思维模式对原有问题的效率进行质的提升”。

比如：通信、交通、医疗、教育、生活……几乎全都是在优化效率。

所以，如果精神不自由，就很难跳出老的思维模式，如果不是对效率的提升，这个创新可能会不接地气。因此，我认为，工程师文化就是自由加效率！

以上列举的这些特征，来源于：Google 的《重新定义公司》（How Google Works）、我在 Amazon 的工作经历、37Signals 的"Rework"、Quora 上的" What Makes Good Engineering Culture? "、 Slideshare 上的 “What Makes Good Engineering Culture”，以及我最近这半年来的一些实践。

由前 Google CEO 施密特编写的《重新定义公司》（How Google Works）一书

自由

工程师文化首先意味着创新文化。因为工程师都是有创新冲动的人，而创新的源泉来源于精神的解放，精神自由才会引发各式各样的奇思怪想。

因此他们才会有常人觉得不可能的疯狂想法和想象力，而这些想法和想象力导致了创新。

精神上的自由具体表现在以下六个方面：

1. 自我驱动。自己管理自己是最好的管理，最失败的管理是家长和保姆式的管理，从兴趣出发的工作才可能迸发出真正的动力。

2. 灵活的工作时间和地点。工程师们的工作更多的是脑力工作，而不是体力工作，工作上时间和地点的自由安排可以让工程师们的脑力工作更有效。

Remote（远程办公）是一个很不错的工作方式，开源社区基本上都是使用这钟方式。

3. 信息平等。这意味着，全体员工得到的是原始信息，而不是被管理者们层层加工消化后的信息，信息的屏蔽很容易造成误解和完全错误的行为。

信息的平等，既包括战略、方向、目标、财务等大信息，也包括文档、代码和知识的共享等小信息。

同样，平等也表现在意见表达上，任何人都有表达自己的意见和建议的平等机会，这样才会激发出更多的思路和思辩，从而才会有更多更好的思路出现。

在 Google，除了代码全员共享，还有 Thanks God, It’s Friday 的文化，每周五高管们会和员工在一起，面对面回答员工提出的各种尖锐问题；在 Amazon，代码和文档基本上对全员开放，包括财务报表也对员工开放。

另外，亚马逊所有最牛的 Principle SDE（资深技术专家）隔三岔五都会有一个 Principle Talk（有很多 Talk 相当令人开脑洞）。

还有 Amazon 内部每年会选出一批公司最聪明最有想法的人开会，讨论公司下一步的发展战略，并可以把相应的 KPI 直接传递给 Senior VP。

4. 不害怕错误。处理错误的正确姿势是分析和总结教训，而不是惩罚犯错人。前者让人改善进步，后者让人萎缩不前。工程师最大的错误就是不敢犯错，最大的问题就是不敢直面问题。

5. 宽松的审批系统甚至没有审批系统。

审批通常暗示着三件事：

• 对人的不完全信任

• 繁琐的流程

• 思维上的束缚

这些都是创新和想象力的天敌。一个公司的监管、审批、流程越重，这个公司的活力也就越差。

6. 20% 的自由时间。这是 Google 提出来的，员工有 20% 自由的时间做自己想做的项目，Gmail 就是这么诞生的。

效率

工程师天生是追求效率的。有人说认为程序员花大量的时间做自动化的工具，还不如人肉的效率高。

比如写自动化的脚本花 5 个小时，而重复做这件事 200 次只花 3 个小时。有这样的理解的人根本不懂工程师和工程。

一方面，这个工具可以共享重复使用，更多的人可以从中受益。更重要的是，这是一种提高效率的文化，它会鼓励和激发出更多这样的事情发生。

如果公司管理者因为一个程序员花大量的时间开发自动化的工具，而认为这个程序员没有效率，并且对他批评甚至惩罚的话，那么这个管理者就完全扼杀了提高效率的文化。

人类之所以比别的动物聪明就是会使用和发明工具，而古语也有云：“工欲善其事，必先利其器”。

看看美军的装备你就知道战争工具的好坏有多重要了，一个公司的强大之处在执行力，而执行力的强大之处在于你有什么样的支持工具。这些，已经不是工程师文化，而是人类发展的文化。

对于工程师文化来说，尤其是在软件工程领域，提升工程效率具体表现在如下七个方面：

1. 简化。简化不是简陋，简单的东西通常意味着用户更好理解，也意味着更容易的维护和运维。

就像阿里推行的“小而美”、乔布期推崇的“没有产品手册简单易用的产品”、Amazon 推行的 Working Backwards 里说的那样。

一个新的产品或功能，产品经理需要写三个文档：媒体公关文、用户手册、常见问题，三个文档总共加起来不超过两页 A4 纸，且不准用任何图片说明，目的就是为了让产品简化和容易使用。

2. 残酷无情的推行自动化。编写程序的最本质的目的就是自动化，对于自动化来说，不仅仅只是消除人肉的重复劳动，更重要的是，很多事情人的力量完全比不上机器。

比如：增加一台机器，程序运算在秒级就可以完成，而人是永远不可能达到这样的速度。

再比如：电商中用程序管理数量巨大的订单自动化系统，增加再多的人都不可能像机器那样完成的又好又快。

自动化需要大力开发提高生产力的工具，比如：持续集成，持续部署，自动化运维，基础自动化运维，甚至自动化的运营工具。

3.避免无效率的组织架构和无效率的管理。

这体现在以下这些方面：

• 扁平化的组织架构。

• 努力用自动化工具取代支持型的工作。

• 不超过 10 个人的全栈小团队。

• 不按人员的技能分工而是按其负责的产品或功能分工。

• 开会不是解决问题，开会是表决提案。

• 通过产品的目标或信条来减少沟通和决策过程。

比如，Amazon 里的每个部门、每个团队、每个产品都有自己的信条，这个信条标明了要什么不要什么，这样可以避免很多扯皮和难缠的选择。

我们来看看 AWS 的几个信条：运维是最高优级的——这意味着只要是会让运维变得复杂的需求都可能被工程团队拒掉。

Throughput & Latency（吞吐量和延迟）不能更差——这意味着功能要为性能让路，因为性能变差了，用户就要购买更多的资源。

4.正确的组件抽象。抽象是简化的一部份，最重要的是，抽象意味着技术能力的输出，无论是内部的其他团队还是外部的团队。

比如：Google 的 MapReduce/BigTable/ProtoBuffer，FaceBook 的 Thrift，还有 Amazon 内部的 Web Service 框架 Coral Service、处理日志监控的 Timber，以及全线 AWS 产品都用到的 Amazon Lock Framework（一个分布式锁框架）……

5.开发高质量的产品。因为高质量的代码，不但可以易于修改和维护，还可以因为较少处理线上故障，从而有更多的时间去为未来做更多创造性的工作。

这意味着需要有非常严谨的 Design Review，Code Review，以及测试。

6.不断的提高标准以及招聘最好的人。如果一个公司或一个团队想变得越来越好、越来越强大的话，就必须要不断提高自己的工作标准。

提高工作标准意味着要不断地培养和招聘更好的人才。在 Amazon 和 Google 的招聘系统中都有一个叫 Bar Rasier 的职位，这个职位就是为了提高招聘标准而设立的。

7.创建一个持续改善的文化。一个好的组织和团队，需要全体员工一起不断反思前进。

在微观层面上，在项目做完后需要有一个总结会分析项目中的得失，在故障出现后，需要有故障分析会。

在 Amazon，严重的故障需要写一个 COE（Correction of Errors）的文档，其中有一节叫“Ask 5 Whys”，让你问自己关于这个故障至少 5 个为什么。

在宏观层面上，一家公司每年都应该做一定的工作数据分析或是员工调查。比如，是否招聘到了不错的人、工作的投入产出比、员工在哪些地方花费时间等等，然后不断的用技术手段来改善。

Amazon 每年的工程师员工调查表是我见过的最细的调查表了， 表中的问题除了针对公司、管理层、文化等方面。

还包括日常工作、开发环境、持续集成、测试自动化、产品质量、软件架构、软件维护、线上问题处理、年度计划、数据仓库建设、通用工具投票……这个员工调查直接导致公司对工程的投资方向。

工程师文化如何落地？

如果你要让一种企业文化在公司内得到执行，有下面几个手段可以选择：

“政治”手段

招聘、绩效考核和升职。比如，你要落地工程师文化中的简化和自动化，那你在招聘的时候，需要把懂简化和喜欢自动化的人招进来。

然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么？自动化了什么？如果没有，不但不能升职，绩效还可能不达标。

“经济”手段

让不做这件事的成本 > 要做这件事的成本。然后，正常的人类都会选择成本低的方案。

比如，如果你要推行 Design/Code Review/UT 以提高质量，你就把 QA 和 Ops 团队全挪到一边去，让 Dev 团队自己测试，自己负责。

这样等这些 Dev 重复多次手动测试，处理多次线上的弱智故障，他们就会自然而然的写自动化测试和做 Code Review 了。

而 QA 和 Ops 团队只是帮 Dev 你做工具罢了，而测试和运维的事全是你 Dev 的 Ownership，出了故障也是 Dev 自己负责。

于是，他们就会发现，不做 Code Review 和 UT 的成本远远大于做 Code Review/UT 的成本，他们就会去做成本低的事了。

最后，工程师文化要落地，还有几个小条件：

• 团队要小，Ownership 很重要，Eat Your Own Dog Food。 没有人帮你擦屁股，自己的屎自己吃，没有痛苦，不会产生想进步的动力。

• 热爱学习和尝试。学习尝试新的技术，开拓眼界，学习尝试新的思维方式。否则，原有的思维方式只会让你在原地打转。

• 老板更多的相信技术而不是管理。相信技术会用技术来解决问题，而只相信管理，那就只会用制度、流程和价值观来解决问题。

其他

以上这些是我这么多年经历过或看到的工程师文化，最后说说我的几个观点。

996 和加班这件事，对于工程师来说从来都不是问题。在解决技术问题或是创造的时候，工程师是个很自觉的群体，基本不需要他人驱动。

我相信几乎对于所有走上编程这条道路的工程师，基本上都是兴趣所至，他们觉得编程很有趣。

但很多工程师却被一些公司的 996 搞得对编程毫无兴趣，为什么？这些公司就是通过考试/KPI/996这些东西把工程师的兴趣一点一点的磨灭掉、对学习和工作产生了厌倦和讨厌。

另外，文章中我说的这些文化，并不是什么理想主义，而是已经被很多成功的公司使用了很多年。

还有人说，因为中国国情不同所以这些方法并不实用，这更让我费解。中国有全世界数一数二的互联网用户，也有全世界数一数二的市场，不再是以前那个一穷二白的年代，中国的国情到底有哪些不同呢？

我不知道各位工程师为什么而活着？但我觉得，我们选择了一个刺激的职业，也赶上了这个行业大发展的时代。

我们不妨扪心自问一下，你是否愿意让自己的能力、青春和热情就这样被磨灭掉？