工程师文化

工程师文化

什么是工程师文化

我从谷歌工程师文化中学到的 6 个核心原则

https://www.techug.com/post/what-i-learned-from-googles-engineering-culture.html

这有我从谷歌工程文化中获得的六个核心原则，你可能能够从中获益：

把工程资源用于共享工具和抽象概念。

在早期谷歌在工具和抽象概念上大力投资，例如Protocol Buffers，MapReduce，BigTable和其他在工程中自始至终都会用到的东西。解决问题好的态度并使得每个人能够接受已经带来巨大的收益。每个团队都花费较少的心理周期选择使用哪个工具，专注于工具的团队能够更关注提升工程生产力，和改善已经使用的工具和服务。每个团队可能使用截然不同的工具链，这也意味着当你学习了基本单元结构后，更容易理解许多项目背后的设计。这个方法的负面影响就是有些时候你可能感觉你的case是被强行塞入一个特别的良好支持的工具，即使它不是最好的。

*在新工程师培训中*投资可重复使用的训练材料。

我在谷歌能够迅速变得如此高产的一个原因是公司在培训材料上面花了大力去投资，其称之为Codelabs，Codelabs包括了公司的核心抽象模型，解释它们为什么被设计出来，突出代码库的相关片段，以及通过实现练习验证理解它们。如果没有它，我将会花更多的时间来学习各种我需要去了解的各种技术，这也意味着我的队员要花费更多的精力向我去解释它们。我在谷歌这样积极的经历，强有力的影响了我在后来的Quora新人培训过程中大力推崇Codelabs使用的决定。

标准化编码约定。

每个关于空格、大小写、行长度、是否使用智能指针等约定，可能似乎是不重要的，但是到了谷歌这样的大规模时会带来巨大的影响。我不是第一次承认，当代码校验人员挑刺我的代码令我感到十分不愉快，就因为我没有正确的缩进或在行长度超出了规定的两个字符。但是因为大家都遵循同样的约定，使得浏览代码变得大大容易。当更换团队或在跨部门项目中工作时，这几乎没有额外支出去学习新团队的约定。当团队规模很小时，约定是那种很容易被忽视的东西，但是在代码和团队规模逐渐壮大在这方面越来越做出改变，这样你事实上希望从始至终都是一致。如果可能早期在约定一致性上保持一致，或者使用谷歌开源的风格指南。

通过代码复审（Code Review）提升代码质量。

对每次改变进行代码复审减缓了迭代更新的速度，但是提升了代码质量，新工程师收到反馈后，他们需要迅速的采取最佳的实践并专注于公认的代码质量等级。总体的代码质量越高，也就意味着新工程师在模仿周围人员的代码同时，初期就会写出更加简洁的代码。因此，代码复审有助于公司在较大规模上位置较高的软件质量。

用正确数据解决很多问题。

谷歌研发主管Peter Norvig经常谈到在解决复杂问题上“不合理的数据有效性”。正确的数据能够帮助你了解用户，划分办公室政治，解决争论，并让你跟上进度。开发日志和数据基础工具，如Sawzall和MapReduce，使谷歌的工程师从大量数据中筛选出来变为可能。

自动化测试来衡量你的代码。

谷歌有十分强烈的单元测试文化，“厕所测试”就是一个例子，差不多我每做一次代码的改动都伴随一个单元测试，代码复审员将会严格地检查他们。这让开发变慢，但它也意味着成百上千的工程师可以改变代码库中的同一部分而不会牺牲过多的质量和可靠性。谷歌以同样的方式在共享工具上进行投入，它也会共享测试框架，并通过最好的测试实践让大家写测试变得更容易。

如何在团队建设工程师文化？阿里资深技术专家这么做

https://segmentfault.com/a/1190000015413903

why？

极端的工程师文化产生少数几个极端成功的公司以及大多数死得很惨的公司。

What？

工程师文化 vs KPI文化

• 工程师文化是由内而外的引导和自然发生， KPI文化是由外而内的信仰和强行注入。
• 工程师文化着眼未来， KPI文化活在当下。
• 工程师文化痛恨KPI，我不爱的我不做，我爱的我疯狂。 KPI文化唯KPI说话，爱不爱都要像战士一样完成。

https://www.zhihu.com/question/22168420

一言蔽之，就是一切以解决问题为导向的工作文化。认同这种文化、执行这种方针，并不要求当事人本身是个工程师。

工程师文化以解决问题的第一线人员为核心，除部分公司发展方向的制定者外，所有其他人员均为第一线人员服务。层级要扁平，第一线要具有极大的自由度，权责要向下转移。

一个人的地位、声誉、威望全都归结到一点上——你在多大程度上能够解决问题。一个优秀的一线问题解决者的收入高于中层管理人员是很正常的。

工程师文化里面，有领导层级，但在具体的问题上，只有一个判断谁的意见更重要的准则，那就是谁的方案产生的结果更好。背景、资历、年龄、官位，所有的一切都不顶用，只有一种东西最重要，就是你的方案好用。就算你是常春藤毕业的，你的方案没有一个三本毕业生好用，你的地位、声誉和威望就比不上后者。在讨论问题时，不存在层级。权威来源于经验和解决问题的成功率，而不是官阶。

工程师文化不讲意识形态，不看怎么说，只看怎么做。在工程里面，只有“这顶用”、“It works”，没有“这正确”、“It’s correct”。工程里面大家信奉的只有一条：“实践是判断真理的唯一标准。”吹得再天花乱坠，未经实践检验，都会被怀疑。

工程师文化不在乎加不加班，不在乎是不是办公环境里堆一些非常geek的东西，其关键在于，当问题出现的时候，那种“一切以解决问题为导向”的内部组织模式和思维方式。

此外，真正的工程师一般还会强调“发现问题-了解背景-分析问题-集思广益-制定计划-解决问题”整个流程。必要时，工程师可以放弃了解和分析问题，而直接解决问题（在很多时候这是可能的），在事后才分析问题的缘由。工程师还要理解理论模型和实际情况总是存在差异，好的纸面方案，即便在模拟中性能优良，在实践中也未必有优势。在成本允许的情况下尽可能试错才是关键。当然，这些“工程师的文化”未必包含于企业的“工程师文化”中。

这是属于创造的浪漫，来自于改造这个世界的不安分。拿起厚重而锋利的冲锋锯的时候，你的灵魂仿佛与百万年前那个举起木棒的先祖相连。这，就是工程师。

而当上面这些东西，散布在每一个家庭的车库里，散布在每一辆公路上奔跑的汽车里，每一个孩子都知道如何用改锥去拧紧一个螺丝，每一个少年都知道如何用千斤顶顶起车来换轮胎以便继续泡妹子，每一个成年人都知道如何将木板拼搭成漂亮的露台。这种文化，就形成了。

这才是工程师文化。硅谷的年轻人的自由与青春只是它表达的一小部分，而这种文化自身，则要深邃的多，包容的多，广阔的多。

我还记得很多很多年前，我第一次踏进我当时同学家的车库时，看到满墙工具时所感受到的震惊。现在回忆起来，那种震惊里夹杂着一种恐惧。我隐约觉得我发现了，这些国家强大的源头。而我们真的缺少它。

工程师文化，是一种内心的欲望与恐惧的表达。对创造的欲望，对世界的恐惧。因为欲望而创造，因为恐惧而改造。创造世界，改造世界。

下面是我所能想到的关于工程师文化的一些关键点：

\1. 热爱创造。你愿意弄脏自己的手，捏出个什么，搭出个什么，并引以为豪。 \2. 爱你的工具。工具是工程师的命根子。不管是扳手，还是软件，还是报表。它们的祖先，是人类第一个举起的那根木棒。 \3. 永不满足。总有可以改进的地方，总有可以优化的地方，总有可以完善的地方。 \4. 理性思维。不做无用之事。明白实验与犯傻之间的区别。 \5. 好奇。对自己专业的好奇，对不同专业的好奇，对生活的好奇，对世界的好奇，对宇宙的好奇。 \6. 热爱自己的专业，并一直向下挖。 \6. 疯狂到相信自己能够改变世界。这句话最近也很火。但是真的，工程师，确实是这么一群人。而且他们真的在改变世界，已经改变了好几万年了。

伪工程师文化（工程师至上文化）：

硬件： 配Mac（SSD，内存在标配上加倍），双屏显示器（至少Dell吧，国产的牌子没法用），机械键盘，座椅不是Aeron至少也是Embody，降噪耳机，升降办公桌……这些都是标配啦，加分项还有平衡车，健身房，无人机，Oculus，总之是各种新科技的玩意。

管理： 不开会（工程师不喜欢面对面的同步交流，我们会用代码和你交流）

弹性工作制（晚上美剧和AV看的比较晚，11点之前到公司就差不多了）

项目进度：请让我先评估一下，前面的程序员代码不规范又没有注释，让我接手还不如我重写，至少也要重构一下吧，进度嘛自然要延期。什么时候能完成？那可不好说，我要先评估一下。

Bug：要允许程序员犯错，另外对我们来说有没有bug不重要，快速上线迭代吗。什么，你说并没有快速上线？我不是说了要先重构嘛。

目标：KPI是什么鬼？不要对我们搞什么绩效考核。

氛围：必须酷啊

心态：易怒（动不动就特么的，sb，qnmlgb的），脆弱（至少被很多答主描述的易受伤害），在非代码领域，逻辑混乱的完全不像工程师。

商业：赚钱不重要。

沟通：销售是傻×，产品经理是傻×，HR是傻×，财务是傻×，行政是傻×，老板是傻×，甚至用户也是傻叉。我为什么要和傻叉沟通？好吧，就算他们不是傻叉，但是他们不是可有可无的人吗？

这是什么工程师文化，这是工程师至上文化吧？他们会问「难道工程师不是本来就高人一等吗？世界不是注定被工程师控制的吗？」，你去看评论中工程师的留言就知道了。

真正的工程师文化（目标导向的文化）：

顶级的工程师不会只从技术角度看待问题。

工程师知道自己不是科研经费供养的科学家，我们的价值在于解决真正的工程问题。

（就算别人是傻叉的情况下，依然）不延期，高质量交付。

平和坚定，想想自己是能改变世界的人，怎么可能易怒和脆弱。

身体力行，看看扎克伯格对亲自写和审核代码迷恋就知道了。

**好奇心，理解和尊重商业，善于合作。 ** 真正工程师文化与上面的伪文化在有些方面（比如更好的工作设备）并不冲突，差别在于，他们到底把什么放在前面，是否本末倒置，因果倒置。

——补充一条，在任何组织中任何岗位都应该拥有的文化——

平等。

我不知道你怎么定义“工程师文化”和“地气”。 如果你所指的“工程师文化”的具体特征是：

1. 广泛的技术人员对专业的认同和自身作为专业人士的归属感
2. 以获得专业成就为荣耀，以专业特长获得尊重和理解
3. 技术人员对于经自己手出品的产品怀有荣辱感，并作为展现才华的唯一途径
4. 存在不影响技术工作的“极客”现象，乐于追求创新和完美的原因仅仅是因为有趣或值得别人的尊重。

*如果你所指的“接地气”的管理模式的具体管理特征是：*

1. 和专业团队打成一片，亲和力很强的吃喝玩乐
2. 乐于和专业团队交流，并鼓励他们的每个想法
3. 常常关注于技术团队的人，并在细节上予以人文关怀

那么，我可以直接告诉你不管用，而且可能还会有相反的作用。你要明白专业人士的心态和往往存在的不足，而一个文化的养成是持久的，具有明确文化特征的，这里我不分析为什么不管用，且可能相反作用，但相信我，我是个专业人士，同时还带领着具有工程师文化的团队。 ** ** 理想的方式具备几个必须的先决条件：

1. 你的专业团队的领袖是合格的：

2. 1. 专业公信力：这个人在团队中本身就是技术或专业公认最强的人，属于在必要的时刻能够带着所有人“披坚执锐”的，和古代军队一样，文官主将成功的少，武将往往公认高强。
   2. 领导力体现：这个人具有亲和力、说服力和感染力，能够领导人而非仅仅管理人（注意，领导是火热的，管理是冰冷的，我说的是“领导”）

3. 你的团队具备必要的平均技术水平：

4. 1. 有想法：多数的工程师对所在技术专业有想法，哪怕想法不健全，对领域有所理解。具体的展现是讨论技术实现问题时，你能识别出同意的和反对的，清晰看出存在意见和对方案偏见的态度。
   2. 有基础：如果是个士兵，至少是个摸过各种武器的士兵，就算没摸过各种武器，也是见过各种武器，上过战场的士兵，不是以为只在书上见过步枪可用的士兵。各色职业或语言培训学校啥的那就算了。

在上述条件满足的情况下，才说“工程师文化”，否则，“民工文化”或“生产线模式”更管用。”工程师文化”的最终形态是一种精英文化和专家文化的结果，树立文化的方法：

1. 非技术专业人士不要掺和任何技术决策和沟通
2. 其他部门表达对技术团队进步和努力的认可和支持，清晰识别技术团队的每个进步，放大出来，让所有人知道和尊重于进步
3. 对新技术使用和突破性技术创新的奖励力度极大，公司授予的个人职业荣誉感足够强烈，技术领袖给予了极大支持的同时不参与这样的奖励，把荣誉尽量传递到最末端的技术人员上
4. 不合格的专业人员快速解聘，不能有一个混日子的，不能有一个学艺不精靠声音大活着的
5. 技术领袖和技术团队紧密沟通，处处伸手，对细节讲解方法，提出优化余地，说服其更正，鼓励其优化，但绝不替工程师代劳
6. 减少对工程师团队以行政政策或过程为导向的评价管理机制，改为灵活的能力结果激励机制，具体来说，让技术团队推选他们的核心，而不任命他们的核心；让技术人员决定自己什么时间完成工作、加不加班，而不用打卡的方式约束，一切以能力和结果作为导向。

过程中要注意防止技术团队“骄兵悍将文化”的养成。具体方法是：

1. 对结果为导向的评价严格而冰冷，底线清晰不可触
2. 充分尊重技术领袖对技术人员的评价，在底线不触的前提下妥协和坚持并重
3. 严格的预算和工作成果制度，明确的预算和工作成果奖惩，把他们赶在一条船上，非技术管理层不要干预任何过程，但坚决执行结果考评

最后提醒你，“工程师文化”和你的企业的阶段密不可分，不是什么时候发展文化都是好的，具体“企业文化”建设是不适合你，参见我收录的文章：企业文化规划，文章的作者是Ben Horowitz 是硅谷著名风投 Andreessen Horowitz 的联合创始人及合伙人。也是 Opsware（前身是 Loudcloud，现被 HP 收购）的联合创始人兼 CEO。他曾在网景公司负责过几个产品部门。他还是 Capriza、Foursquare、Jawbone、Lytro、Magnet、NationBuilder、Okta、RapGenius、SnapLogic 及 Tidemark 等公司的董事会成员。

How？

工程师文化的前提条件

信任：leader和产品对工程师绝对的信任是工程师文化的最基本条件。如果他说要用一个更优雅的方法解决一个问题，但要花更多的时间，请你选择相信他。好的工程师非常懒惰，他这么做一定是为未来的工作提高效率。

卓越的技术领袖存在：领导如果对技术没有信仰，只把技术当成工具，就很难说这个团队会有工程师文化。说白了不是每个不懂技术的领导都懂得欣赏优雅代码产生的美和对未来产生的深远影响。

技术列为KPI：在我参加晋升面试的时候，50%以上的技术人员讲的都是产品（what），而不是技术（how），并且他们都晋升了…..这源于业务BU总是把业务当成KPI的唯一衡量手段：技术好不好有什么关系？今年不出事，明年我已晋升。如果没有技术KPI，技术就会总被放在次优先级。

工程师文化的特征

小团队：7-12人的团队是比较适合的团队大小。有人用pizza团队来形容一个团队的大小，就是一两张pizza可以喂饱这支团队。facebook和google经常有2-3个人的团队，小团队有如下特征（中文为个人即兴翻译，可以选择忽略）：

• Move Fast and Break Things（不破不立）；
• Huge Impact with Small Teams（以少为多，精准打击）；
• Be Bold and Innovative（勇敢追求卓越）；

技术创新：团队必须坚信技术可以为业务带来不同于现在的可能性，现在没看见不代表它不存在。技术挑战产品是因为也许你不知道还有更好的技术和架构可以更简单更有效地完成一个业务任务。团队激励不单纯以业绩为主的技术的创新，比如：Google每个工程师都有20%的时间可以用于研究自己喜欢的技术，而不是跟Google相关的业务。

技术决策权大：尊重技术决策的前提就是信任技术决策，而不是简单粗暴地说：“为什么完不成？随便叫一个程序员就可以完成。”工程师未必在所有产品特性的定义上有决策的能力，但在优先级和排期上是可以从技术角度给出决策。所有的业务deadline倒排都在一定程度上逼迫技术做出妥协，并且这些妥协慢慢变成合法理由：我的代码不好的原因是业务压力太大。Note：工程师们不要为自己邋遢的代码找理由，代码对于一个软件工程师就是尊严。

技术数据可视化：可视化技术相关数据包含圈复杂度、测试覆盖率、重复率等等，对数据好的工程师给予掌声。但是，好数据给予的是掌声而不是奖金，所有数据都可以被造出来，这是个充分但不必要条件——好的代码数据肯定好，数据好的代码不一定是好代码。

分享多会议少：宁愿少开会掰扯这个应该谁做，这个P1应该谁来背，也要多听技术高手讲一个技术细节，大家都应该沉下心来沉淀一下自己的专业知识。

https://www.zhihu.com/question/52220971

• 从组织层面讲：

• • 不会让外行领导内行

  • • 我相信很多技术团队都吃过外行领导内行的苦头。
    • 为什么在技术团队里不能让外行领导内行？第一，外行不知道一件事的实操需要哪些人付出多少代价，所以经常表现出“不尊重技术团队的劳动”，无他，可能只是因为ta不知道。第二，ta只关注业务层面的事情，对技术趋势、技术内功、基础架构完全无感。

  • 人与人之间关系简单

  • • 不管是谁，说对了就要点赞，说错了就要反驳。错了就是错了，错了就要承认，错了就要纠正。

  • 会少

  • • 除非必要，就不需要开会，尤其是开大会。
    • 哪种会可以多开？技术分享讲座。哪种会可以少开甚至不开？头脑风暴会。

• 从工作内容讲：

• • 愿意投入人力物力在增长内功、有助传承的长期项目上。

  • • 在面对安全、审计、质量控制等要求时，更愿意选择用“机器”解决，而不是增加流程。
    • 即以前经常说的『凡是被不断重复的过程，将其工具化，绑定到自动化流程之中，减少不必要的心智负担』。

  • 分享学习氛围浓厚

  • • 第一不会以部门为沟壑。第二鼓励与引导跨部门输出价值观。第三，安排适当工作时间以补充新知，反哺团队。

谢邀。在我看来： \1. Code Review是必须的； \2. 在开发估时中一定要包括完善文档的时间； \3. 如果使用git，一定要有规范的git workflow，最好在issue中可以看到需求的完整实现； 以上都只是一些开发规范，至于团队建设，我只希望各部门沟通顺畅即可。 ps.请不要再给我安排一个改了数据库中数据，结果在url中id写错说返回结果不对的测试。作为一个后端开发，我真的很无奈╮(╯▽╰)╭ 比较重要的， \4. 团队内的每个人至少要各方面都相似，差别不那么大才适合敏捷开发，不是每个团队都适合敏捷开发，如果流动性极大，且团队内的人差别较大的团队，用敏捷开发，只会导致文档不完善，代码不规范，以及文化流失严重；（这一点极为重要） \5. 不加班，有较高的工作效率，在工作时间内完成自己的任务； \6. 有时间可以提高自己丰富自己去学一些新的东西； \7. 推荐使用尝试新的技术。

拙见：

\1. 不要让非技术人员参与任何技术决策。可以提建议，但没有决策权，即便是不懂技术的大 Boss。

\2. 技术团队中除了做决策的那个 leader，其他人基本做到每个人都相似的话语权，至少没有明显的上下级之分，更不会因为个人资历来决定某个人的技术观点的对错与否，一切就事论事、以理服人。

\3. 鼓励探索新技术，更不要用任何单一指标（尤其是工作时间）来简单的衡量一个工程师的绩效。鼓励为某一类问题寻求更通用的解决方案，而不仅仅为了某个具体业务的 DDL 放弃研究（当然，可行性和得失得具体情况具体评估）。

\4. 鼓励为提高工作效率进行各种形式的 OA 开发，建立公司内部的代码库，每个开发者都可以提交自己写的模块。类似于公司内部的 GitHub，可以考虑把对内部库的贡献程度纳入对开发者的评估中。更具体的，可以适当有一些黑客马拉松之类的活动。

\5. 公司内部有技术书库，而且有简单的申购流程。

\6. 每个技术团队有专门的运营或者策划等处理这个技术团队任何与外部的非技术沟通，屏蔽不必要的非技术信息对开发者的干扰。

\7. CEO 是技术出身并打心底里热爱技术，或者 CTO 在整个公司拥有话语权。

\8. 必须写单元测试，必须进行 Code Review。

另外，推荐阅读： \1. 创业及管理：构建利于探索的工作环境：https://zhuanlan.zhihu.com/p/20400750 ； \2. 谈谈工程师文化：https://zhuanlan.zhihu.com/p/20225815；

崇尚自由

• 有灵活的工作时间和地点
• 上下级之间是扁平化的管理
• 有自由的时间和机会去尝试自己的想法
• 内部人员可以自由的进行技术分享

追求效率

• 简化组织架构和管理
• 招聘最优秀的人才
• 技术团队不要让非技术人员管理
• 少开没用的会
• 对技术组件进行抽象化，对代码进行高效重用。如 Google 的代码库。

勇于突破和创新

• 技术团队最好小而美，员工能积极学习新技术，补充技术栈
• 实施员工一些靠谱的想法，内部竞争，比如腾讯的微信就是内部创业，还有豌豆荚内部孵化的开眼等等
• 不断反思，做高质量的产品，及时放弃一些很糟的产品
• 如果有足够的资金，成立未来技术研究实验室，放眼未来。如 Google X ，华为 2012 实验室等
• 拥抱开源

最后，老板最好是工程师出生，不然就不能愉快的抢月饼了。

1.适当的工作量.从而有时间学习新知. 2.有学习氛围,定期有技术分享课. 3.不要让不懂技术的人到技术团队BiBi 4.不以加班多为绩效考核标准. 5.不以出bug为由扣钱扣奖金. 6.团队有mm 7.有明确的加薪升职制度. 8.弹性上班时间 9.懂得鼓励培养新人. 10.禁止搞各种xx哥,xx爷的称呼 暂时能想到的就这么多了.

陈皓：什么是工程师文化？

https://kb.cnblogs.com/page/553682/

　四年前，我在 QCon 上演讲了一个《建一支强大的小团队》（整理后的 PPT 分享于这里）提到了工程师文化，今天，我想在这里再写一篇关于工程师文化的文章，一方面是因为我又有了一些想法和体会，另一方面，因为我也正走在创业的道路，毫无疑问，要建一个有浓重的工程师文化的团队或公司，所以有必要把自己的相关想法开有成白底黑字的“字据”，以供打自己的脸——“要是未来没有做到，这篇文章就打我未来的脸” “这篇文章太幼稚了，未来的我会打我现在的脸”，我希望是前者。

　　Again，这篇文章不是招人的贴子，因为我觉得，招聘第一重要的事，不是发招聘广告或是找猎头挖人，而是先得让自己变成一个能配得上真正工程师的公司，然后再谈吸引人的事。

　　为什么要工程师文化

　　看看最近二十年来社会的发展，计算机和互联网已经渗透到了这个社会的每一个角落，各式各样的计算机技术成为了整个世界发展的强大引擎，各式各样的创新，无论是业务创新还是技术创新，都是依托于技术的快速演进，技术成了解放生产力提高社会运作的效率的中坚力量。以美帝国主义为首的技术创新公司着着实实的改变着这个世界和人类的生活和生产习惯。

　　今天，每个从事计算机行业的技术人员都应该感到幸运，因为，我们不但选对了行业，也出生在了正确的时代，可能感受到前所未有的刺激和变化，相比起我们的父辈，我们的人生，能经历这样的时代，实在是一种幸运。所以，选对了职业并出生在了正确的年代的我们，只是需要思考的一个问题就是，我是否呆在了正确的地方？

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

• 运营或销售驱动型的公司。这类的公司以运营和营销见长，技术对于他们来说，更多的只是为了支持大规模的营销活动，以及成本上的控制，所以，基本上来说不需要技术创新。这种公司最大的问题就是缺乏安全感。
• 产品驱动型的公司。这类公司以产品见长，通过创造能提升用户生活体验的产品见长，技术对于他们来说，除了支持大规模的在线用户之外，他们会更多的去寻找那些为了增强用户体验，提高整个业务流程效率的技术创新。比如：UI 的交互方面的，整个业务流程方面的。这种公司最大的问题，就是容易被别人模仿和抄袭。
• 技术驱动型的公司。这类的公司相信技术能改变世界，他们更多的是用强大的工程技术来创造有颠覆性的东西，更多的是用各种自动化的技术取代人类。比如：近代的蒸汽机技术取代了大量的人工，数字技术取代了大量信息传递的人工，现代，这类公司还希望通过人工智能来取代愚蠢的人类来做决定。这种公司最大的问题就是可能做出叫好不叫座的东西。

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

　　无论你有多么的看不起技术人员，你都无法否认，你今天的生活相当的依赖这帮工程师，没有他们，你恐怕都不知道怎么生活了。邓爷爷几十年前就说过——“科学技术是第一生产力” ，无论什么样的科学技术的理论要落地都会依赖于工程技术有多先进。

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

　　工程师文化的特征

　　我下面罗列的这些特征来源于，Google 的《重新定义公司》，我在 Amazon 的经历，37Signals 的《Rework》，Quora 上的 What Makes Good Engineering Culture? Slideshare 上的 What Makes Good Engineering Culture，以及我最近这半年来的一些实践。

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

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

　　创新不是凭空出现新的东西，其实，观察一下人类的发展史，不难发现，几乎所有的创新基本上跳出原来的思维模式用新的思维模式对原有问题的效率进行质的提升。比如：通信、交通、医疗、教育、生活……几乎全都是在优化效率。

　　所以，如果你的精神不自由，你很难跳出老的思维模式，你用老的思维模式你一定不会想到新的方法和方式，如果不是对效率的提升，这个创新可能会不接地气。

　　自由

　　首先，工程师文化意味的创新文化，工程师都是有创新冲动的人，因为手里有创造技能的人通常都想创造点什么。而创新的源泉水来源于精神的解放，精神自由才会引发各式各样的奇思怪想，才会有常人觉得不可能的疯狂想法和想像力，而这些想法和想像力导致了创新。

　　精神上的自由具体表现在：

• 自我驱动。自己管理自己是最好的管理。最失败的管理就是家长和保姆式的管理。兴趣出发的工作才可能迸发出真正的动力。
• 灵活的工作时间和地点。工程师们更多的是脑力工作，而不是体力工作，工作上时间和地点的自由安排可以让工程师们的脑力工作更有效。Remote 是一个很不错的工作方式，开源社区基本上都是这钟方式。和 Remote 有关的话题可参看这本书《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 就是这么出来的。

　　效率

　　工程师天生是追求效率的。有人说认为程序员花大量的时间做自动化的工具，还不如人肉的效率高，比如，写自动化的脚本花 5 个小时，而重复做这件事 200 次只花 3 个小时。有这样的理解的人根本不懂工程。

　　一方面，这个工具可以共享重用，更多的人可以从中受益，而不是微观上的比较。更重要的是，这是一种文化，一种提高效率的文化，他会鼓励更多的这样的事情发生。如果你因为一个程序员花大量的时间开发自动化的工具，而认为这个程序员没有效率，对之批评甚至惩罚的话，那么你就扼杀了提高效率的文化（关于效率，大家可以看看我的另一篇文章《关于加班和效率》，你会真正了解什么是效率）

　　人类之所以比别的动物聪明就是会使用和发明工具，而古语也有云：“工欲善其事，必先利其器”，看看美军的装备你就知道战争工具的好坏有多重要了，一个公司的强大之处在执行力，而执行力的强大之处在于你有什么样的支持工具。这些，已经不是工程师文化，而是人类发展的文化。

　　针对于工程师文化来说，尤其是软件工程，提升工程效率的具体表现如下：

• 简化。简化不是简陋，简单的东西通常意味着用户更好理解，也意味着更容易的维护和运维。就像阿里推行的“小而美”，就像乔布期推崇的“没有产品手册简单易用的产品”，就像 Amazon 推行的 Working Backwards 里说的那样，一个新的产品或功能，产品经理需要写三个文档：媒体公关文、用户手册、常见问题，三个文档不准备超过两页 A4 纸，且不准用任何图片说明。
• 残酷无情的推行自动化。编写程序的最本质的东西就是自动化，看看人类发展史上自动化了多少东西。对于自动化来说，不仅仅只是消除人肉的重复劳动，更重要的是，很多事情人完全干不过机器，比如加一台机器，程序在秒级就可以完成，人是永远不可能达到这样的速度的。自动化需要大力开发提高生产力的工具，比如：持续集成，持续部署，自动化运维，基础自动化运维，甚至自动化的运营工具。（Amazon 的软件工程中对自动化和简代相当迷恋）
• 避免无效率的组织架构和无效率的管理。这体现在这些方面：1）扁平化的组织架构，2）努力用自动化工具取代支持型的工作，3）不超过 10 个人的全栈小团队，4）不按人员的技能分工而是按其负责的产品或功能分工（关于分工，请参看《让我们来谈谈分工》），5）通过产品的目标或信条 Tenets 来减少沟通和决策过程（Amazon 里的每个部门，每个团队，每个产品都有自己的 Tenets，这个 Tenets 标明了要什么不要什么，比如：AWS 的几个信条：运维是最高优级的——这意味着只要是会让运维变得复杂的需求都可能会工程团队被拒掉，Throughput & Laentcy 不能更差——这意味着，功能要为性能让路，因为性能变差了，用户就要买更多的资源）
• 正确的组件抽象。抽象是简化的一部份，一方面，抽象意味着重用和通用，另一方面抽象意味着强大的扩展性，以适配各种可能性。最重要的是，抽象意味着技术能力的输出，无论是内部的其它团队还外部的团队。比如：Google 的 MapReduce/BigTable，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 每年的工程师员工调查表是我活那么大见过的最细最细的调查表了， 问题除了对公司、经理、文化的，还有从，日常工作、开发环境、持结集成，测试自动化、产品质量、软件架构、软件维护、线上问题处理、年度计划、数据仓库建设、通用工具投票……这个员工调查直接导致公司的对工程的投资方向）

　　工程师文化如何落地

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

• 通过政治手段：你需要把三个地方——招聘、绩效考核 & 升职。比如，你要落地工程师文化中的简化和自动化，那你你在招聘的时候，你需要把懂简化和喜欢自动化的人招进来，然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么？自动化了什么？如果没有，对不起不但不能升职，绩效可能还不达标。
• 通过经济手段：让不做这事的成本 > 要做这个的成本。然后，正常的人类都会选择成本低的方案。比如，如果你要推行 Design/Code Review/UT 以提高质量，你就把 QA 和 OPS 团队全挪到一边去，让 Dev 团队自己测试，自己负责，而 QA 和 OPS 团队只是帮你做工具罢了，而测试和运维的事全是你 DEV 的 Ownership，出了故障也是 dev 自己负责，于是，他们就会发现，不做 code review 和 ut 的成本远远大于做 code review/ut 的成本，他们就会去做的。

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

• 第一，团队要小，Ownership 很重要，Eat Your Own Dog Food。 没有人帮你擦屁股，自己的屎自己吃，没有痛苦，不会产生想进步的动力。
• 第二，热爱学习和尝试，学习尝试新的技术，开拓眼界，学习尝试新的思维方式，否则，呆在原地，原有的思维方式只会让你在原地打转转。
• 第三，老板更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。

　　其它

　　说了这么多，时代还在发展，不过，这是我这么多年经历或看到的工程师文化的东西了。最后吐几个槽——

　　对于 996 和加班这个事，对于工程师来说从来都不是问题，在解决技术问题或是创造的时候，工程师是个很自觉的群体，基本不需要有别人驱动，工程师是最乐意 Work Hard 的人了。我相信几乎所有走上编程这个职业的人来说，基本上都是兴趣所至，觉得编程很有趣，但却被各个公司 996 搞得对编程毫无兴趣。为什么，你们这些公司要向中国的教育学习呢？人家本来对这事有比较高的兴趣的，但就是要通过考试/KPI/996 这些东西把人家的兴趣一点一点的磨灭掉，把人变成机器、奴隶、牲口，让人对学习和工作产生了厌倦和讨厌，会是你们这些管理者们所希望的？是不是只有把人变得不思进取了，你们才会管理？就像《软件开发中的两种管理方式》中说的第一种人一样？

　　另外，我不知道，为什么我一说这些东西，就会有很多人（包括程序员自己）来和我说我是个理想主义者，这些已经不是什么理想了，已被很多成功的公司用了很多很多年了。只是你没有见到过罢了。还有的人说，因为中国的国情不同。这更让我费解了。这让我想到了当年大清朝派了一堆人出国考察后回来后，说外国的那套共和的东西不符合中国国情，最终也在历史的潮流中被淹没掉了。另外，什么叫“中国的国情不同”？中国有全世界数一数二的互联网用户，也有全世界数一数二的市场，不再是以前那个一穷二白的年代了，中国的国情到底有哪些不同呢？

　　我不知道各位工程师是为什么活的？但我觉得，我们选择了一个刺激的职业，也赶上了这个行业大发展的时代，我们不妨扪心自问一下，你是否愿意让自己的能力、青春和热情就这样被磨灭了？

　　（全文完）

• 上一篇 如何做一对一面谈
• 下一篇 Windows通過x11 forward用ui訪問樹莓派的server