在我看来，这个世界上有三种商业公司，
-
运营或销售驱动型的公司。这类的公司以运营和营销见长，技术对于他们来说，更多的只是为了支持大规模的营销活动，以及成本上的控制，所以，基本上来说不太需要技术创新。这种公司最大的问题就是缺乏安全感。
-
产品驱动型的公司。这类公司以产品见长，通过创造能提升用户生活体验的产品见长，技术对于他们来说，除了支持大规模的在线用户之外，他们会更多的去寻找那些为了增强用户体验，提高整个业务流程效率的技术创新。比如：UI 的交互方面的，整个业务流程方面的。这种公司最大的问题，就是容易被别人模仿和抄袭。
-
技术驱动型的公司。这类的公司相信技术能改变世界，他们更多的是用强大的工程技术来创造有颠覆性的东西，更多的是用各种自动化的技术取代人类。比如：近代的蒸汽机技术取代了大量的人工，数字技术取代了大量信息传递的人工，现代，这类公司还希望通过人工智能来取代愚蠢的人类来做决定。这种公司最大的问题就是可能做出叫好不叫座的东西。
这三种公司都可能成功，也都有问题，但是，无一例外，他们都需要强大的技术支撑，只不过，他们把技术所放在的位置不一样。
无论你有多么的看不起技术人员，你都无法否认，你今天的生活相当的依赖这帮工程师，没有他们，你恐怕都不知道怎么生活了。邓爷爷几十年前就说过——“科学技术是第一生产力” ，无论什么样的科学技术的理论要落地都会依赖于工程技术有多先进。
所以，在今天，作为一个 IT 或互联网公司，“工程师文化”不是一个问题，而是一个常识！
0.1.1 工程师文化的特征
我下面罗列的这些特征，来源于：Google 的《重新定义公司》，我在 Amazon 的工作经历，37Signals 的《Rework》，Quora 上的 What Makes Good Engineering Culture? Slideshare 上的 What Makes Good Engineering Culture，以及我最近这半年来的一些实践。
简单说来，我可以简单的把这多的工程师文化的总结成两大类：“自由” 和 “效率”。
本来还应该有个“创新”，但我个人认为，创新的前提是——在自由的环境下对提高效率的痴迷，就一定会发生创新。
创新不是凭空出现新的东西，其实，观察一下人类的发展史，不难发现，几乎所有的创新基本上跳出原来的思维模式用新的思维模式对原有问题的效率进行质的提升。比如：通信、交通、医疗、教育、生活……几乎全都是在优化效率。
所以，如果你的精神不自由，你很难跳出老的思维模式，你用老的思维模式你一定不会想到新的方法和方式，如果不是对效率的提升，这个创新可能会不接地气。
因此，我认为，工程师文化就是自由加效率！
0.1.2 自由
首先，工程师文化意味的创新文化，工程师都是有创新冲动的人，因为手里有创造技能的人通常都会有想创造点什么的冲动。而创新的源泉水来源于精神的解放，精神自由才会引发各式各样的奇思怪想，才会有常人觉得不可能的疯狂想法和想像力，而这些想法和想像力导致了创新。
精神上的自由具体表现在：
-
自我驱动。自己管理自己是最好的管理。最失败的管理就是家长和保姆式的管理。兴趣出发的工作才可能迸发出真正的动力。
-
灵活的工作时间和地点。工程师们更多的是脑力工作，而不是体力工作，工作上时间和地点的自由安排可以让工程师们的脑力工作更有效。Remote 是一个很不错的工作方式，开源社区基本上都是这钟方式。和 Remote 有关的话题可参看 37Signals 的这本书《Remote》
-
信息平等。这意味着，全体员工得到的是原始信息，而不是被管理者们层层加工消化后的信息，信息的屏蔽很容易造成误解和完全错误的行为。信息的平等，大的包括战略、方向、目标、财务，小的包括文档、代码、和知识的共享等。同样，也表现在意见表达上，任何人都有可能表达自己的意见和建议的平等机会，这样才会激发出更多的思路和思辩，从而有不同的更好的思路出现。而不是，大家都看到了问题，而没有人敢说。在 Google 除了代码全员共享，还有 Thanks God, It’s Friday 的文化，每周五，高管们会出来，任员工提各种尖锐的问题，在 Amazon，代码和文档基本上全员开放，包括财务报表也对员工开放，另外，除了所有的 NB 的 Principle SDE 隔三岔五都会有一个 Principle Talk（有很多 Talk 相当令人开脑洞），还有 Amazon 内部的 Up the River 文化，每年会选出一批公司最聪明最有想法的人集思会，讨公司下一步的和战略，并可以把相应的 KPI 直接按给 Senior VP。
-
不害怕错误。处理错误的正确的姿势是分析总结教训，而不是惩罚故障人。前者让人改善进步，后者让人萎缩不前。最大的错误就是不敢犯错，最大的问题就是不敢直面问题。
-
宽松的审批系统甚至没有审批系统。审批通常暗示着三件事，1）对人的不完全信任，2）繁琐的流程，3）思维上的束缚。这些都是创新和想像力的天敌。一个公司的监管、审批、流程越重，这个公司的活力也就越差。
-
20%的自由时间。这是 Google 公司提出来的，员工有 20%自由的时间做自己想做的项目，Gmail 就是这么出来的。
0.1.3 效率
工程师天生是追求效率的。有人说认为程序员花大量的时间做自动化的工具，还不如人肉的效率高，比如，写自动化的脚本花 5 个小时，而重复做这件事 200 次只花 3 个小时。有这样的理解的人根本不懂工程。
一方面，这个工具可以共享重用，更多的人可以从中受益，这次我花 5 个小时开发这个工具，下次只用 1 小时改一下就可以用在别的地方，这是着眼于未来而不是眼下的成本。更重要的是，这是一种文化，一种提高效率的文化，他会鼓励和激发出更多的这样的事情发生。如果你因为一个程序员花大量的时间开发自动化的工具，而认为这个程序员没有效率，对之批评甚至惩罚的话，那么你就扼杀了提高效率的文化（关于效率，大家可以看看我的另一篇文章《关于加班和效率》，你会真正了解什么是效率）
人类之所以比别的动物聪明就是会使用和发明工具，而古语也有云：“工欲善其事，必先利其器”，看看美军的装备你就知道战争工具的好坏有多重要了，一个公司的强大之处在执行力，而执行力的强大之处在于你有什么样的支持工具。这些，已经不是工程师文化，而是人类发展的文化。
针对于工程师文化来说，尤其是软件工程，提升工程效率的具体表现如下：
-
简化。简化不是简陋，简单的东西通常意味着用户更好理解，也意味着更容易的维护和运维。就像阿里推行的“小而美”，就像乔布期推崇的“没有产品手册简单易用的产品”，就像 Amazon 推行的 Working Backwards 里说的那样，一个新的产品或功能，产品经理需要写三个文档：媒体公关文、用户手册、常见问题，三个文档总共加起来不超过两页 A4 纸，且不准用任何图片说明，目的就是为了让产品简化和容易使用。
-
残酷无情的推行自动化。编写程序的最本质的目的就是自动化，看看人类发展史上自动化了多少东西。**对于自动化来说，不仅仅只是消除人肉的重复劳动，更重要的是，很多事情人完全干不过机器。**比如：加一台机器，程序在秒级就可以完成，而人是永远不可能达到这样的速度的，再比如：电商中用程序管理数量巨大的订单的自动化系统，加再多的人都完成的不可能像机器那样完成的又好又快。自动化需要大力开发提高生产力的工具，比如：持续集成，持续部署，自动化运维，基础自动化运维，甚至自动化的运营工具。（Amazon 的软件工程中对自动化和简代相当迷恋）
-
避免无效率的组织架构和无效率的管理。这体现在这些方面：1）扁平化的组织架构，2）努力用自动化工具取代支持型的工作，3）不超过 10 个人的全栈小团队，4）不按人员的技能分工而是按其负责的产品或功能分工（关于分工，请参看《让我们来谈谈分工》），5）开会不是解决问题，开会是表决提案，6）通过产品的目标或信条 Tenets 来减少沟通和决策过程（Amazon 里的每个部门，每个团队，每个产品都有自己的 Tenets，这个 Tenets 标明了要什么不要什么，这样可以避免很多扯皮和难缠的 trade-off 的决择，比如：AWS 的几个信条：运维是最高优级的——这意味着只要是会让运维变得复杂的需求都可能会工程团队被拒掉，Throughput & Latency 不能更差——这意味着，功能要为性能让路，因为性能变差了，用户就要买更多的资源）
-
正确的组件抽象。抽象是简化的一部份，一方面，抽象意味着重用和通用，另一方面抽象意味着强大的扩展性，以适配各种可能性。最重要的是，抽象意味着技术能力的输出，无论是内部的其它团队还外部的团队。比如：Google 的 MapReduce/BigTable/ProtoBuffer，FaceBook 的 Thrift，还有 Amazon 内部的 WebService 框架 Coral Service、处理日志监控的 Timber，以及全线 AWS 产品都用到的 Amazon Lock Framework（一个分布式锁框架）……
-
开发高质量的产品。因为高质量的代码，不但可以容易的修改和维护，还可以因为少处理线上故障，从而有更多的时间去为未来做更多创造性的工作。这意味着需要有非常严谨的 Design Review，Code Review，以及测试，关于 Code Review，可以参看这篇文章《从 Code Review 谈如何做技术》，关于严谨的测试，可以参看这篇文章《如何做性能测试》
-
不断的提高标准以及招聘最好的人。取法其上，得乎其中，取法其中，得乎其下，取法其下，法不得也。如果一个公司或一个团队想变得越来越好，越来越强大的话，就必需要不断的提高自己的工作标准，提高工作标准意味着要不断地培养和招聘更好的人。在 Amazon 和 Google 的招聘官中都有一个叫 Bar Rasier 的人，这个人就是为了提高招聘标准而设立的。
-
创建一个持续改善的文化。一个好的组织，一个好的团队，是需要不断反思前进的，这需要全体员工一起来的。微观层面上，在项目做完后需要有一个总结会分析项目中的得失，在故障出现后，需要有故障分析会，反思得失，在 Amazon，严重的故障，需要写一个 COE（Correction of Errors）的文档，其中有一节叫“Ask 5 Whys”，让你自己问自己至少 5 个为什么。在宏观层面，一个公司每年都应该做一定的工作数据分析或是员工调查，比如，是否招聘到了不错的人、工作的投入产出比，员工在哪些地方花时间了，等等，然后不断的用技术手段来改善。（Amazon 每年的工程师员工调查表是我活那么大见过的最细最细的调查表了， 问题除了对公司、经理、文化的，还有从，日常工作、开发环境、持结集成，测试自动化、产品质量、软件架构、软件维护、线上问题处理、年度计划、数据仓库建设、通用工具投票……这个员工调查直接导致公司的对工程的投资方向）
0.1.4 工程师文化如何落地
如果你要让任何文化在公司内得到执行，你有下面几个手段可以选择：
-
通过政治手段：你需要把住三个地方——招聘、绩效考核 & 升职。比如，你要落地工程师文化中的简化和自动化，那你你在招聘的时候，你需要把懂简化和喜欢自动化的人招进来，然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么？自动化了什么？如果没有，对不起不但不能升职，绩效可能还不达标。
-
**通过经济手段：让不做这事的成本 > 要做这个的成本。**然后，正常的人类都会选择成本低的方案。比如，如果你要推行 Design/Code Review/UT 以提高质量，你就把 QA 和 OPS 团队全挪到一边去，让 Dev 团队自己测试，自己负责，这样等这些 Dev 重复多次手动测试，处理多次线上的弱智故障，他们就会自然而然的写自动化测试和做 Code Review 了，而 QA 和 OPS 团队只是帮 Dev 你做工具罢了，而测试和运维的事全是你 DEV 的 Ownership，出了故障也是 Dev 自己负责，于是，他们就会发现，不做 Code Review 和 UT 的成本远远大于做 C Code Review/UT 的成本，他们就会去做成本低的事的。
最后，工程师文化要落地，还有几个小条件，
-
第一，团队要小，Ownership 很重要，Eat Your Own Dog Food。 没有人帮你擦屁股，自己的屎自己吃，没有痛苦，不会产生想进步的动力。
-
第二，热爱学习和尝试，学习尝试新的技术，开拓眼界，学习尝试新的思维方式，否则，呆在原地，原有的思维方式只会让你在原地打转转。
-
第三，老板更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。
0.1.5 其它
说了这么多，时代还在发展，不过，这是我这么多年经历或看到的工程师文化的东西了。最后吐几个槽——
对于 996 和加班这个事，对于工程师来说从来都不是问题，在解决技术问题或是创造的时候，工程师是个很自觉的群体，基本不需要有别人驱动，工程师是最乐意 Work Hard 的人了。我相信几乎所有走上编程这个职业的人来说，基本上都是兴趣所至，觉得编程很有趣，但却被各个公司 996 搞得对编程毫无兴趣。为什么，你们这些公司要向中国的教育学习呢？人家本来对这事有比较高的兴趣的，但就是要通过考试/KPI/996 这些东西把人家的兴趣一点一点的磨灭掉，把人变成机器、奴隶、牲口，**让人对学习和工作产生了厌倦和讨厌，会是你们这些管理者们所希望的？是不是只有把人变得不思进取了，你们才会管理？**就像《软件开发中的两种管理方式》中说的第一种人一样？