• 黑白色的华为(9) 码农的世界


    工程师profile和工程师文化

    软件工程师简称码农,无论多么伟大的构想也得依靠这些码农一砖一瓦的构建起来。正如前面说述。软件工业本身还依旧处于大规模手工业阶段,是低效的手工业形态。我想这是为什么称作码农的根本原因吧。既然是手工业,那么产出的质量就严重依赖码农的能力和意愿了。这一章让我们探索一下码农的世界吧。

    https://ss0.bdstatic.com/70cFvHSh_Q1YnxGkpoWK1HF6hhy/it/u=395824090,4116909348&fm=26&gp=0.jpg

    自从工业革命以来,码农几乎是最具自我成就感的无产阶级群体。每一个真正的码农内心都认为是自己改变了世界,或者正在改变世界的路上。

     

    所谓工程师文化的建立,就是如何让这些自带革命乐观主义精神的无产阶级持续拥有成就感。

     

    自带成就感的码农都是重度洁癖患者,他们写出来的代码:

    l  干净,整洁

    l  高效

    l  Bug free

    l  即使初期架构稚嫩,但是总有一天会修正过来。

    l  。。。

     

    而失去成就感的码农等同于要他们抛掉改变世界的理想,失去理想的码农和一条咸鱼又有什么区别呢?

     

    坦白来讲,大多数情况下,我在华为看不到这种工程师文化。我很少能在华为看到具有激情的工程师。也许激情在无穷无尽的交付折磨,产品进度中早就给消耗干净了。关于交付,支撑这个话题,前面我已经讲了不少,这里就不累述了。

     

    不论是我还是其他外部公司来华为的码农,和华为培养出来的工程师接触,大家都觉得华为的工程师总是“呆呆”的感觉。无论是做设计,还是写代码,亦或者是处理事情,一根筋。大多数工程师很容易深陷自己的逻辑中而不能自拔。

     

     

     

    上图是我进公司不久发的一个微信截图,不是段子,不是演绎,真实事件(兄弟,得罪了)。我这么说可能会得罪一大票华为的码农,但这确实是我们真实的感受。

     

    华为的工程师,如果给一个很明确的指令性的工作,具体步骤很明确,华为的工程师会完成的很好,很精确,让人放心。但是一旦某个指令是模糊的,不确定性的,方向性的,那么很多华为的工程师就会不知所措了,他们会spin在原地打转。或者是不断的来询问你该怎么办。

     

    有的人把这些问题归结为体力耗尽以后的表现,有一定道理,你如何要求一个体力精力被无穷无尽的交付,conference call,问题定位单给消耗掉的工程师还有余力去拥有工程师文化呢?

     

    这是一种可能性。但也并不是所有的工程师都是这样的,无论如何,我很难从华为的工程师眼睛里看到对技术激情的火花,甚至看不到光泽。

     

    我也说不清楚为什么,如果说工作压力大,生活压力大。但实际上,和大多数人的认知相反,很多西方国家工程师的待遇现在已经逐步在弱于国内了,每一个工程师,无论是西方还是东方,也都面临诸多的生活压力,在任何一个国家,养家糊口对于大多数人来说都不是一件容易的事情。

     

    我们通常认为西方工程师比较懒,没有中国工程师勤奋。这种说法也对,也不对。如果以平均水平来讲,中国工程师的勤奋程度是远超西方工程师的。如果从能力上来说,中国工程师的平均水平也是超过了很多西方公司的。但是,有一个非常有趣的现象。中国的工程师很差的不多,极好的也不多,大多数工程师处于好,不错,或者普通这个区间。而西方工程师我的感觉是不靠谱的不少,中间状态的也不少,但是顶级优秀的比我们要多不少。

     

    为什么西方能有更多的顶级工程师呢?就我的认知总结是:爱好

     

    为什么大多数中国的工程师没有办法成为顶级的技术人员呢?我觉得缺乏爱好是一个核心的原因。就我接触,看到的一些外国很好的工程师,他们就是简单的爱好,只有爱好才能让他天天琢磨,什么技术都经不住琢磨,再难的东西也架不住天天想。而且这些工程师的勤奋程度也是超过我们的勤奋程度的。

     

    贴上一个我的出差报告节选吧,这是我在2017年德国参会的时候现场听到Linus的一段访谈对话。

     

     

    那么具体到如何建立工程师文化呢?就我个人的认知是如何把码农的爱好和他的成就感连接起来。这就又回到品牌上来了,牵涉到一个软件品牌的核心问题。如果这个码农所做的软件在世界范围内开枝散叶,没有什么比这个更能成就码农的满足感了。反过来又会促进码农的兴趣,从而形成良性循环。因此,软件品牌的建设不单单是一个软件体系的建立,同时也是培养一群高水平工程师的道路。

     

    结合之前谈到的现代软件的发展的新模式,实际上3,4个有爱好,有成就感的码农是可以非常高效的完成一个庞大软件系统的主体开发的。

     

    讲完了工程师的profile和工程师文化,再聊聊由这些众多的工程师组成的华为公司吧。

     

    公司profile和公司文化

    开篇我就提到过,华为是一个非常独特的公司,我因为进入公司时间有点长了,很多感觉已经钝化了,而且这个话题并不是这个系列文章的重点。我只讲和我做软件密切相关的一些独特感觉吧。

    如果说排名第一的独特感受的话,首推自信和自卑。

    自信和自卑

    诚如前面所述,一个外来的“砖家”进入华为,看到的是一个充满了矛盾的地方,其中对我来说,体验最强烈的是一方面华为具有极其强烈的自信心,可另一个方面内心深处却又拥有极度的自卑感。这两种感觉如同扑克牌的两面,永不相见,却又贴合在一起。

    在业务发展的层面,华为拥有强烈的自信心,具有睥睨一切对手的战略自信。

    可在实际的工程过程中,对外部世界的任何风吹草动却又如同惊弓之鸟,惶惶不安。

    始终无法进入一种relax的状态。或者说是从容自信的状态。

    惊弓之鸟就无法持久投入,方向转换过快。

    惊弓之鸟难以有决心在软件上有PK的雄心,总是follow的心态,

    事实上,华为已经是千亿美元级别的公司,按理说应该拥有更为从容的气度,更开放的态度。而不是感觉所有的人都很“焦躁”,所有的事情都是“临时抱佛脚”的状态。似乎外界所有的“新技术”都像救命稻草一般。

    至少在做软件层面,这种状态很难有长久的耐心来打磨一个软件产品。非常容易受到外界的影响而左右摇摆。

    只有平和的心态才能把软件做好,火车不怕慢,怕停站,软件开发不怕慢,怕断。华为多的是1000个人奋战3个月的淮海战役模式,却极少有抗战八年,集小胜为大胜的游击战模式。1000个人做3个月的软件铁定好不到哪里去,但是3个人干3年的软件就会非常可怕。

    排名第二的是胜则举杯相庆,败则拼死相救。

    胜则举杯相庆,败则拼死相救

    这个排第二是因为在大队培训中,培训老师讲了很多很多华为文化的点,比如艰苦奋斗,比如狼性文化,踏实务实,等等等等。这些文化我在后续的工作中都或多或少有所感受。唯一印象深刻但是在后续的工作中从未感受到的就是胜则举杯相庆,败则拼死相救。

    可能在早期的华为,这种文化存在过,但是现在却荡然无存了。

    强烈的KPI文化将部门和部门之间,团队和团队之间,工程师和工程师之间变成了敌对关系。你很快会发现,工程师在团队中会很挑活,凡是不显眼的,没法绩效的工作基本上很难推动,勉强能做下去的质量也可想而知。但是,一个体系中,工作的显眼度和工作的重要程度完全没啥关系。

    这些工程师的大忌很快的污染掉一拨拨的工程师。

    l  技术方面还是呆呆的,但是工程师在其它方面开始变的“油”起来。

    l  绩效好的工程师群体口才越来越好,肢体语言越来越丰富,这和普遍认知中的顶级工程师沉默寡言,羞涩腼腆的形象大相径庭。

    l  糟糕的是,毕业生们很快就会进入到某种状态中,一种再也闻不到技术味的状态中。

    l  开始能吵架了,嗓门越来越大,学会不讲理,或者讲歪理了。

    l  工程师开始“创造”,即使行业内普遍共识的no news is the best news的底层软件,平台软件领域也有很多 “good news”了。

    l  。。。。

    KPI是现今公司的通用手段,东西方公司都有,有差别的地方是公司考核强度的不同。强考核和弱考核都有利有弊。

    过强的KPI考核就会造成上面的种种问题。

    过弱的KPI考核会让公司和团队渐渐懈怠,WindRiver后面的衰败根因就是懈怠。

    但是什么是强,什么是弱,这个度如何把握,这个我认为是公司治理中的一个大课题。我这个码农就不瞎扯了。留待公司高层和学术界研究吧。

    我个人的建议是对于工程团队,特别是码农团队,相对弱考评似乎更有利于码农的成长和工程师文化的建立。比如B/B+这样的考评体系是否简化为B一档。

    实事求是

    关于这一点,总体来说,华为还是很合格的,没有实事求是,务实的精神,华为走不到今天这一步。但是,公司大了,公司的年纪增长了,已经开始出现“故事情节”了。这一点我不想谈太多,因为不同层面的视角不同。但是至少有一点我是始终如一的坚持己见:工程师团队是公司最后一个不能讲故事的团队,当工程师团队也开始讲故事的时候,公司的隐忧就已经开始显现了。

    知识老化&人才培养

    这是一个我觉得比较严重的问题,华为整体上在艰难的转型,员工的质量我觉得是top1的问题,东西还是做出来的,即使主观意愿很好,手上的活儿糙也没办法完成公司的转型。就软件领域来说,我看到的几个问题

    人才断层

    人才断层:作为业务主力的16-18这一档次的工程师总体上能力偏弱,核心是动手能力太弱。软件这东西说到底还是一个手艺活,没啥技巧,就是多写。但是目前16-18这一波的工程师面临几个很难的情况:

    n  他们上手的时候面临的就是一个做完了的系统,他们无法了解这个系统的前世今生,只知道现在是这个样子,但是不知道为什么是这个样子,而不是其它的样子。留给他们的工作就是修修补补。很难真正的建立架构设计能力。

    n  开源冲击:由于现代软件的模块化比较好了,很多软件也非常成熟了,留给很多工程师的空间不多。很多时候都只是在开源的基础上修修补补。许多人应该逐步有了体会,修理开源软件越多,自己的整体软件的设计和开发能力就越弱。

    n  越来越依赖外来的专家来做领头羊和头雁,但是我总认为一个公司的技术领头人主体群体应该是自己培养的为主,外来的为辅好像才更合理。至少说明整个公司的培养机制还是运转良好的。

    总体来说,年轻工程师没有犯错的机会了,但是一个码农真正能力的积累不但看他做成功过几个项目,也要看他做失败过几个项目。而且往往从失败中获得的经验远远大于成功所获得的经验。因为只有失败才能刻骨铭心。

    一个从main函数的第一行写到最后return的一个2000行的系统所能获得的能力,远远超过维护一个20万行代码所能得到的能力。

    因此,对于一个团队,如何能不断导入“犯错机会”就是衡量这个团队是否能有持续技术能力提升的重要标志了。

    SE能力PPT化

    在进入华为前,没有SE这种概念。西方公司中,以WindRiver公司为例,其工程师的级别倒也简单,engineer, senior enginer, MTS, senior MTS,。。。基本上工程师只是级别的区分,很少有岗位的区分。码农就是码农,就是干活的,没有非常明显的你是做架构的,你是写代码的这种区分。当然,这并不是说所有的engineer都必须写代码,但是至少有一条是确定的:工程师必须懂技术。

    工程师必须懂技术,这个听起来好像挺搞笑的一种说法。但是这种说法在华为却显得并不那么可笑。不同架构师之间的能力有差异,不同行业,领域的能力模型也会很不一样。但是在我的认知里,架构师,甚至是所谓的总架构师,还是需要对细节有很清楚理解的。否则很难想象怎么去设计东西。工程师懂技术说的是工程师,特别是架构师要对底层的细节要有清晰的了解。

    在华为,我看到了很多PPT架构师,架构师需要写PPT,这是毫无疑问的,但是架构师只会写PPT,这就麻烦了。我看到了太多架构设计是一个框框,再加一个框框,中间拉一根线。表示架构设计完成了。剩下的事情似乎是下面的工程师发挥的空间了。

    至少我认为合格的架构师应该有什么样的能力呢?举个接口设计的例子。

    1.         如果你设计了一个接口,除了PPT上的那根箭头,至少要能明确能说清楚是本地函数调用,还是远程调用。

    2.         如果是本地调用,如果是一个内置的函数,那么怎么抽象抽象,如果是C语言实现,那么是不是一个函数指针集合来实现接口抽象?如果是go语言,那么是使用interface语法进行抽象么?

    3.         如果是本地调用,是否要抽象成插件机制?用什么模式实现插件机制?是使用动态库的load能力来搞,还是在类似go这样的高级语言中直接使用plugin的高级模块来实现?

    4.         接口是不是有版本的概念,如何设计和实现接口版本问题。

    5.         如果是远程调用个,使用rpc还是自己定义的字节流。

    6.         如果是字节流,那么如果有指针,数组,变长字符串等需求怎么办,这些东西的marshal和unmarshal将是一场灾难,怎么办?

    7.         如果是rpc的,至少能在多种rpc方案中选择一个你觉得合理,可靠的。

    8.         Rpc对于不同语言的兼容性。是否java, C,Go…等语言都能试用。适配不同的语言环境,适应未来对接不用的软件系统。

    9.         如果是rpc,是否需要安全鉴权机制。

    10.     如果是rpc,性能考虑如何,相对重量级的rpc会不会导致性能的不可接受。

    11.     。。。。

    你看,即使是一个接口设计,可能需要考虑的方方面面也会很多。如果对细节不了解,如何能回答上述问题呢?更严重的问题是,可能都无法列出上面的问题列表。对架构师来说,这是比不知道怎么回答这些问题更具灾难性。

    这一小节有点吐槽,自黑的感觉,因为我没有经历过很大型的公司,也许,在大公司,其架构师的标准profile确实就是PPT架构师。这里就作为一个参考输入吧。至少,我觉得,架构师们在离开华为以后,还得能找到一份工程师的工作养家糊口吧。

    技能的老化

    现代软件开发,新语言,新工具层出不穷,一个工程师需要不断的尝试新的工具,新的语言,了解新的进展。这是为啥码农确实比较辛苦的原因。但是这又是不得不做的事情。特别是高职级的码农,更是要不断上手去尝试。

    以开发语言为例,虽然做OS的人C是最为重要的开发语言,但自打我4-5年前开始接触go语言以后,目前基本上绝大多数的项目我都要求使用go开发了。

    1.       开发速度快,一天几百行的代码,甚至上千行的速度是可能的,这在C语言来看根本不可能。

    2.       不容易出错,没有了内存管理,语法逻辑简单,没有了C++令人炫目的模板。我觉得如果用go语言还能把程序写崩掉的工程师就直接打C走人把,别浪费时间培养了。

    这些都大大加速了软件开发的速度,同时提升了质量。

    而最近又出现了用rust这样的语言来完成底层系统,甚至是OS的开发的趋势,所有的这些都是需要工程师持续的去学习和掌握的。对架构师来说,更需要了解这些新的东西,知道可以用什么新的技术解决什么问题。

    软件的世界还有太多的东西每天都在变化,诚如我前面所说,考验架构师的越来越是对外界世界的敏感程度和了解程度,而不是对自己已有工作的熟悉程度。

    对于架构师是不是需要亲自上手写程序这个问题,我不认为架构师必须要上手写程序,因为一个好架构师写程序的效率也最多强过3-4个普通工程师,而且写程序这事情,绝对不存在很牛的架构师就能信手拈来,写完就万事大吉的情况。架构师也需要全情投入才行。在华为强交付的模式下,一个无法详细了解前后文,时间无法保证的架构师写程序对项目来说绝对是噩梦,但是架构师需要具有写程序的能力,而且这种能力越强越好。至少,他不会被下面的工程师糊弄住。

    公司的各个业务团队应该多引入这些新时代的开发语言,当然,如果我们的编译器团队能搞出开发效率更高的自己的语言那就更棒了。

    人才导向

    如前面所述,现代软件体系已经发展的如此复杂和多样,对人的要求并不是降低,而是越来越高。因此,通常一个工程师成长的周期也越来越长。这个和很多人的看法是相反的。不少人认为随着高级语言的普及,零部件的丰富,人才的培养周期会短很多。实际上是相反的。至少对华为这样的公司是不成立的。

    语言的进化,零件的丰富只是让做一个系统简单了一些,或者说是用胶水粘合出一个模样简单了很多,但是不代表这东西能做好。做好,做精一个系统的难度不是降低而是增加了。因为你必须花更大的精力来把已经不错的东西做的更好。

    这就好比20世纪30年代如果要获得奥运百米冠军难度很大。21世纪的奥运百米竞赛,即使小组赛第一轮被淘汰的运动员,他们的成绩也远远好过30年代的奥运冠亚军。运动科学的发展,饮食的发展,训练的发展并没有降低这个运动的难度,反而使得竞争更激烈,难度更大。

    科学领域似乎也在印证这个趋势,最近看到的资料,诺贝尔奖早期平均年龄是37岁,近年已经变成47岁了。

    因此,从我的经验来看,很难有35前能够有多高造诣的码农,天才也许有,平时看不见。啰嗦这么多,还是要回归到公司的人才导向上。

    和绝大多数中国公司一样,年龄是一个横亘在中国码农前面的一个几乎很难逾越的门槛,看到的,听到的多是要寻找“少年天才”“青年才俊”。这种导向没有问题,本质上是一种强制新陈代谢的机制,永远保持肌体的活力。但是过于强调这种导向,会带来非常多的副作用。

    l  没有那么多天才,应当承认,我们生活中所能接触到的都是凡夫俗子。一群凡夫俗子中提拔了一个“天才”,对组织的杀伤力有多大就不用多讲了。

    l  现代科技,软件越来越要求长时间的沉寂了,而不是短时间的爆发。一个超新星的爆发是之前集聚了几十亿年的力量,但是如果你天文望远镜观测星空,每天都能发现几十次超新星爆发。但是华为每天焦躁的问大家:每天世界都有那么多超新星爆发,你们为啥还不爆发。

    l  越是基础性的东西,其积累周期越长,以我熟悉的OS为例,下面连接芯片,上面对接云计算。这差不多需要一个物理学家即要精通微观的量子力学,又要熟知宏观的天体物理。我自己感觉自己35以后才算有点入门的感觉,而且也仅仅就是入门而已。

    因此,从我看来,关键不是拔苗助长式的寻找“青年才俊”“寻找天才”,而是:

    1.      如何让工程师有远大的理想(无产阶级的成就感),有目标感。

    2.       如何让他们能踏踏实实的积累技术。

    而这些,和年龄真的没啥关系。激发所有码农的工程师文化才是真正的人才导向的核心。而且,现实情况中,大多数码农也确实希望能认认真真的做技术,这一点是符合码农的无产阶级自觉性的。

    持续积累

    既然前面已经提到了专注和持续积累,就软件领域。公司的持续积累还是略显不足。除了我前面提到的缺乏品牌意识,软件知识硬件辅助部件的问题以外,公司对软件领域的持续积累的认识也是不足的。

    普遍上,公司对硬件层面的认知和积累认可度是比较好的。以我接触的海思为例。虽然海思对做软件的人总不是那么nice,做软件的人也很难理解做芯片的思维回路。但是这不妨碍我还是比较羡慕海思的状态。海思上上下下还是有一种令人羡慕的专注度。每一个系列的芯片,开始总不是那么好,但是你可以很清晰的看到每一次新片子可喜的变化,即使现在依然有差距,但是我还是相信他们的片子迟早会成功。

    但是公司的各个软件层面,却很难看到这样清晰的节奏和持续感。我们的软件开发更多像是脉冲式的发展模式。而不是小步幅的持续慢跑式的模式。做软件才真的是比马拉松。

    前面已经有过讨论,软件如果要能有很好的成绩,很大程度上要有比做芯片更大的耐性和坚持才行。因为我们面临的是从个人到巨头全方位的竞争。

    压力&管理方法

    在华为,压力这事儿自不必多讲,压力不是坏事,有了压力才有动力。但是压力大和合理的管理方式并不冲突,也不等同于叫骂。

    对于我们这些外招“砖家”,整体上公司还是非常客气的,很少出现当面对骂的情况,但是对于华为土生土长的自己人,就没那么客气了。一言不合就开骂是常有的事情。正如我文章标题所讲的那样,这是一种管理风格,没有对和错之分,华为用这种管理方式登顶了世界。但是至少从我的感觉上看。这种高压式的管理方式,会带来两种负面的影响:

    1.       人被骂多了就会显得比较木讷,工程师显得呆呆的。工程师没有情趣,不会讲笑话,不会开玩笑。这种氛围本身就是对创造力的一种压制。

    2.       人被骂多了就皮了,表面很顺从,实际上内心是不在乎的。凡事不是发自内心的认同去做,这事儿做的指定不靠谱。

    对于这个纯管理层面的事情,我不做过多的探讨,也说不上有什么建议。只把问题抛出来把。

    专注&学习能力

    前面讲了很多我认为的“问题”,但总体上我依然还是很看好华为。经历过不同公司的起起伏伏,我个人总结一个公司真正长治久安需要两个根本能力:

    1.       公司管理层的专注度,从上到下管理层的专注度。一个公司是否在走下坡路,其中最重要的一条是看看它的各级主管是否还懂业务,是否精力还在业务上,是否还保持勤勉。整体上看,华为的各级领导还是专注在业务上的。这是华为前进的基本保障。

    2.       快速学习能力(或者说是纠错能力):这个不用多说,华为在这方面是极其优秀的,只要华为决定做什么,还是具有非常快的吸收和消化能力。而且在公司,很少听到自己对自己很满意的评价。基本上都是以吐槽为主,吐槽的内容也是以我们为什么做不到xxx,为什么我们比不上xxx的内容。这是好现象。说明华为还始终保持着自我反省,自我改革的动力和意愿。

    因此,虽然在之前的章节我提出了很多问题,但是如果从大的层面来看,只要公司能保持以上两种能力,公司的发展我觉得不会有大的问题。只是调节的慢和调节的快的问题。

    用一句话来结束我对工程师以及华为profile文化的探讨吧。希望公司能保持业务的专注和强大的学习能力。逐步找回正在丧失的工程师文化和协作精神。

    马上要进入最后的部分了,至此,我已经写了9章,从宏观到微观都写了不少,该到做一个总结的时候了,甚至是想想做点什么的时候了。终章:不是答案的答案

  • 相关阅读:
    Axel linux下多线程下载工具
    使用Scala编写Spark程序求基站下移动用户停留时长TopN
    编写Spark的WordCount程序并提交到集群运行[含scala和java两个版本]
    使用Eclipse编译运行MapReduce程序 Hadoop2.6.0_Ubuntu/CentOS
    Eclipse上Hadoop插件中Run On Hadoop原理[转]
    apache官方中文hadoop说明文档地址
    如何在Windows下面运行hadoop的MapReduce程序
    通过web界面查看hadoop集群运行日志的地址
    linux命令-查看当前目录下所有文件的大小:“ll -h”
    BZOJ3979 : [WF2012]infiltration
  • 原文地址:https://www.cnblogs.com/gongxianjin/p/15703753.html
Copyright © 2020-2023  润新知