什么是工程师文化?

什么是工程师文化?

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

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

为什么要工程师文化

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

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

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

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

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

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

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

工程师文化的特征

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

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

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

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

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

因此,我认为,工程师文化就是自由加效率!

自由

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

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

  • 自我驱动。自己管理自己是最好的管理。最失败的管理就是家长和保姆式的管理。兴趣出发的工作才可能迸发出真正的动力。
  • 灵活的工作时间和地点。工程师们更多的是脑力工作,而不是体力工作,工作上时间和地点的自由安排可以让工程师们的脑力工作更有效。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就是这么出来的。

效率

工程师天生是追求效率的。有人说认为程序员花大量的时间做自动化的工具,还不如人肉的效率高,比如,写自动化的脚本花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每年的工程师员工调查表是我活那么大见过的最细最细的调查表了, 问题除了对公司、经理、文化的,还有从,日常工作、开发环境、持结集成,测试自动化、产品质量、软件架构、软件维护、线上问题处理、年度计划、数据仓库建设、通用工具投票……这个员工调查直接导致公司的对工程的投资方向)

工程师文化如何落地

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

  • 通过政治手段:你需要把住三个地方——招聘、绩效考核 & 升职。比如,你要落地工程师文化中的简化和自动化,那你你在招聘的时候,你需要把懂简化和喜欢自动化的人招进来,然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么?自动化了什么?如果没有,对不起不但不能升职,绩效可能还不达标。
  • 通过经济手段:让不做这事的成本 > 要做这个的成本。然后,正常的人类都会选择成本低的方案。比如,如果你要推行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。 没有人帮你擦屁股,自己的屎自己吃,没有痛苦,不会产生想进步的动力。
  • 第二,热爱学习和尝试,学习尝试新的技术,开拓眼界,学习尝试新的思维方式,否则,呆在原地,原有的思维方式只会让你在原地打转转。
  • 第三,老板更多的相信技术而不是管理。相信技术会用技术来解决问题,相信管理,那就只会有制度、流程和价值观来解决问题。

其它

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

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

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

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

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (42 人打了分,平均分: 4.71 )
Loading...

什么是工程师文化?》的相关评论

  1. 感觉要做到真正的工程师文化,还是需要一帮__极其聪明__的人,再加上一些基本的制度保障,就八九不离十了。

      1. 哥你真是说出了俺的心声啊,他们做项目全靠蛮力玩,没有一点点艺术细胞,我还小我拦不住可咋办,咋办→_→

  2. @airekans 应该是:不需要任何“保障”制度吧,一群极其聪明的人就够了。最优秀的团队只需要一个阿姨给卖外卖就够了。

  3. 写得真好,希望你能早日建立这样的公司和这样的公司文化。

    有几个错字:
    思维上的束服 => 思维上的束缚
    占争工具的好坏 => 战争工具的好坏

  4. 找bug的来了, 下面这段话
    > 所以有必要把自己的想关想法开有成白底黑字的“字据”,
    “想关想法”应该是“相关想法”

  5. 这是我第一次见到这个词,原来我们还可以有这些文化建设。也实在感叹AWS这类型的国外大公司思想的先进,真是一些能够创造新价值观念的人的聚集地。

  6. 我认为本质上工程师文化是向往自由的,而且优秀的工程师总会自发地变好(可能听起来太乐观了哈哈)
    所以好的公司只要能把他们聚在一起,提供宽松的环境,工程师们就会自己发展出工程师文化啦~

  7. 耐着性子看完了全文(因为略长),但是收获还是很大,感触很多,尤其同意最后关于996的观点。让一个程序员为了正常的业务需求加班从来都不叫事,但是所有程序员都会很反感为了加班而加班。因为(我经历的)加班大多数都是由于其他相关人员某些低效的行为造成的,为什么我能做到高效却要为别人的低效买单,简直是荒唐!

  8. 认同!我觉得要落实这种工程师文化,“不断的提高标准以及招聘最好的人”这一点最重要。提高效率的前提是能力要够,每一名成员都有意识做提高效率的事情,整个团队文化自然就形成了。

  9. 收获很大。我觉得最吸引我的就是“残酷无情的推行自动化”、“灵活的工作时间和地点”以及“信息平等”。

    残酷无情的推行自动化: 我觉得在中国的公司,所谓的敏捷总是沦为形式;在呆过的大型互联网公司所眼见,一旦推行敏捷,就大量离职,原因不外乎工具根本不到位却盲目的搞形式,代码越来越烂,工程师越来越不爽。与其搞敏捷的虚空形式甚至沦为PMO和Leader互相政治倾轧的工具,不如老老实实的提升自动化的水平,自动化到一定程度工程师会自己敏捷的。

    灵活的工作时间和地点:一个月内,效率不是平均的,管理者却期望工程师线性产出。我渴望灵活的工作时间,让我有时间去做充电的事情。

    信息平等:往往不知道怎么回事,就上一个不知所谓的项目,今天还搞得热火朝天,明天就没了,信息不平等,只有干,干的毫无价值和成就感。

  10. 这篇文章分享到朋友圈的链接,在手机打开之后还是像打开电脑网页一样, 页面字体没有放大,阅读起来比较费力,是不是可以改改?but,这篇文章不能同意更多了!

  11. 自由这个东西是必要的,但也必须要谨慎的使用,在一定章程上面的自由才能够更好的激发创新。

  12. 看到这篇文章特别有共鸣。

    > 工程师文化如何落地

    除了政治部分,我所在的团队已经实行了很久,如果要说有多久,从我加入前就有,至少3年。

    再说自动化

    * 每当一个 PR 提交之后, CI 会自动运行 build pipeline,并且只运行到测试部分。
    * 每当一个 PR merge 到 master 之后, CI 依旧自动运行,并且直接部署到 pre-prod 环境 (testing/E2E/staging)

    创建 PR -> Design Review -> Coding -> Code Review -> merge to master -> deployment …

  13. 可惜可惜,各大公司需要的并不是工程师,而是农民。
    养鸡场需要的不是能下出金蛋的黄金鸡,而是大量的能下普通蛋的母鸡。
    写代码的如今已是血汗工厂里的廉价劳动力,连名义上的“工程师”都做不到了。

  14. 在一个 「运营或销售驱动型的公司」 实践工程师文化有些难度,很多时候是独善其身。扭转强大的旧思路要花费很大力气。

  15. 感觉国内技术驱动型的公司寥寥无几,产品驱动型公司貌似也不多。但往往能做出大事甚至推动科技和人类进步的是两种公司类型的结合。自己期待的是一个有更浓厚产品和技术氛围的公司,除去代码以外,工程师能够自发的探讨产品和设计,能从多个角度进行深入实践。。而不是普遍常见的一种工作流:产品 – 设计 – 开发。这种工作流的好处是各司其职,考验团队配合,但很容易会将我们的思维局限在自己的领域。在我的角度看来,工程师文化不仅仅是撸代码,全栈也不是多端开发。一个不会思考产品不会设计和交互的工程师绝不是一个好的全栈。同理,不懂代码的是设计师也不是个好产品😂

  16. 国内技术驱动型的公司确实寥寥无几,但这不代表了,小团队不可以有自己的工程师文化。手中无剑,心中有。

  17. 我相信几乎所有走上编程这个职业的人来说,基本上都是兴趣所至,觉得编程很有趣

    这句话,培训机构的存在怎么说。

  18. 恕我挖苦一句,很多人说道工程师文化基本就是一种近乎傲慢的职业内部的自我吹捧和互相吹捧。
    就好象搞金融的那帮人自我感觉良好一样

  19. Amazon的软件工程中对自动化和简代相当迷恋 —— 简化
    这意味着只要是会让运维变得复杂的需求都可能会工程团队被拒掉 —— 都可能会被工程团队拒掉
    无论是内部的其它团队还外部的团队 —— 还是
    《如果做性能测试》 —— 如何做性能测试?

  20. Bug:简单说来,我可以简单的把这多的工程师文化的总结成两大类:“自由” 和 “效率”。
    Fix:简单说来,我可以简单的把这么多的工程师文化的总结成两大类:“自由” 和 “效率”。

  21. 我们这做外包的公司看来远远不能做到的啊. 大家要吃饭,自由和容错怎么会轻易地允许?

  22. 请求搂主一个问题,我们一个项目在验证suse12和suse11下性能的时候,发现相同tps的情况下suse12下进程的CPU占用比SUSE11高10%左右,suse11 和suse12下编译的代码一样, 性能测试的模型也一样,通过perf调优工具输出分析发现,SUSE12下基本上每个函数的CPU占用都比SUSE11要高一点,其中HASH函数的CPU占用差异最大,现在没有思路,怀疑跟编译器优化选项有关,请问楼主对SUSE12和SUSE11的差异还有研究,忘指点一二

  23. 楼主太理想了,讲的政治一点,公司高管里得有真懂技术的,真敢给技术团队背黑锅的。一旦kpi miss就让高管滚蛋的公司太多了。大环境有了,小弟们才敢放开干。关于kpi,槽点就更多了!!!

发表评论

电子邮件地址不会被公开。 必填项已用*标注