2019年,德国,纽伦堡
前段时间,朋友圈被《我是技术总监,你干嘛总问我技术细节》刷屏了,微信群里也有不少讨论。就我所看到的情况,各种意见都有。有人认为“技术人不能丢掉技术”,也有人认为“工作做到上面都是考验人性”,还有人认为“工种不同,技术细节不清楚很正常”。借这个机会,我想谈谈自己的经历。
十多年前,我曾经去BAT中的一家面试过(到现在也是我唯一一次BAT的面试经验)。当时刚毕业几年,写代码解决一般问题任务已经“得心应手”了,各方面知识也懂一点,会搭MySQL的Master-Slave,会用Memcache,HTTP协议也基本熟悉……
在那个许多公司还在为100万PV就头疼的年代,这样的水准在技术上算比较领先了。所以我以为,这次面试应当是十拿九稳。
结果大大出乎我的意料,可以说是“惨败”。
我熟悉的领域一个也没有谈起,我解决的问题一个也没有问到,却问了一大堆“技术细节”问题。比如一个int变量要占几个字节,字符串的查找-替换怎样最快…… 在学校里,我最熟悉的Java,C和C++的课程只是囫囵吞枣,这类知识早就忘记了,做题比较多的也是离散数学、数值计算等等,工作了之后一直做Java,根本不会深入到这样的细节。所以,面试结果用“惨败”来形容,是一点不夸张的。
当时我觉得很委屈,对已经工作的人,为什么要考这些细节的书本知识?而且是日常开发根本用不到的书本知识?难道不应当重视实际经验吗?
等再工作几年我逐渐发现,这些原本不是“细节的书本知识”。如果你要解决的问题稍微有点挑战性,没有现成工具可以利用,只能靠自己思考和分析,或者借鉴其它现成工具的原理,就离不开这些看不起的“细节知识”。
比如,后来(一直到如今也是)我经常说:“好的程序员不会凡事都靠实地测试,而是会预先计算”,就必须用到这些细节的知识。拿如今最热门的“高并发”应用来说,单个节点每秒处理多少个请求,每个请求包含哪些数据,每部分数据的大小是多少,机器的带宽是多少,网卡的吞吐率可以达到多少……能把所有这些数据综合起来,心里就大概有了把握,而且这种理性结算的结果,远远比“写个程序去压测”要靠谱得多。
所幸我在这次面试失败之后几年就领悟到这个问题,于是又花时间(那时候996还很少见)把数据结构、算法、网络、系统结构等等基础知识全部梳理了一遍。如今回想起来,当时的这轮梳理确实值得,自己后来受益匪浅。
行业内有句话说:搞技术的不玩虚的,就服实打实的解决问题的本事。我认为这句话是成立的。在我走上技术负责人的岗位后,也解决过不少技术上的疑难杂症,尤其是我“本职”领域之外的问题。比如困扰大家很久的接口概率性失败的现象,最后诊断出是证书问题;又比如HTTP能通SSH不能通的问题,最后发现是TCP的TIME_STAMP配置问题;再比如面对不稳定的遗留系统,迅速拿出方案隔离不稳定部分,为技术改造赢得时间……
能解决这些麻烦的问题,自然能赢得各团队伙伴的信任,不过我并非这些领域的专家,只是多亏了之前对基础知识和技术细节的掌握,再加上学习和分析而已。
在很长的时间里,我一度非常相信“技术负责人就是要懂细节”,否则内心也很慌张。对细节的把握,让我感到踏实、放心。同时,我也热衷于在面试中考察候选人对细节的了解,如果不了解细节,这个人就很浮躁。换句话说,优秀的技术人员应当像把篦子,一路梳理过去,各种细节了如指掌,所有的问题原形毕露,这样工作才称职,自己才放心。
然而,随着面临问题的复杂,职位的升高,我发现自己日益焦虑,因为这是“不可能的任务”——技术细节太多了,想要对每个细节都了如指掌只会让人疲惫不堪;技术人员也太多了,想要在每个人那里都保持权威也会让人高度紧张。
到最后我发现,这已经不是一个用不用功、专不专心的问题,因为精力有限,要照顾的方面又太多,所以无论你多么用功,多么专心,都会感到力有不逮、左支右绌的局面。看来,篦子这种模型有点问题——篦子当然好,但通常都不长,一手能够拿住,如果要覆盖很宽的面,就非常吃力。
那么,该怎么办呢?如果自己找不到出路,我尝试去观察其他人是怎么做的。观察一段时间之后,我还真有很大收获。
最大的收获是,我发现没有人可以了解所有的细节。如果光看媒体,似乎很多“大佬”无所不知、无所不晓,但仔细分析就发现,“大佬”往往只有在自己熟悉或者有充分准备的领域可以谈得很深,遇到自己不熟悉的领域,他们要么不发声,要么说错了但会有公关团队去掩盖。
不可否认,一些企业里的高级管理人员或者创业者仍然保持了早期的工作作风,或者大概是为了保持“权威的存在感”,喜欢抓细节,喜欢就细节问题发表自己的看法。在面试中,也有一些面试官喜欢过分追究细节,不断拿特别细特别专门的问题来考验候选人,营造自己的优势。
但仔细观察往往发现,这些人看起来无所不知,但如果是在他们不熟悉的领域,这样做多半没有好处。“抓细节”往往导致本末倒置,“随时就细节问题发表看法”往往容易适得其反,“用细节问题让候选人难堪”可能错过有潜力的候选人,这一切,都抬高了企业的运营成本。
我经常说,IT行业可以从其它领域借鉴经验,对技术细节的把握也是如此。以我对其它领域的了解,许多成功的技术领导者,其实并不关心细节,至少不会在细节上花太多的精力。
比如上世纪“太空竞赛”中,美国载人航天工程推进部分的总工程师冯·布劳恩,他最关心的是火箭分几级最合适,登月计划到底采用哪个方案更好,是地球轨道交会还是月球轨道交会。至于火箭制造的各种细节,其实他没有精力去操心,也轮不到他操心(参考《系统问题应当如何排查?看看NASA著名的“10厘米发射”吧》)。
再比如我军的高级将领里,真正会打枪、枪打得好的没有几个,但这并不妨碍他们叱咤风云、攻城掠地。更典型的例子如1955年授衔上将的张爱萍将军,在后来主抓“两弹一星”工程,指挥我国第一颗洲际导弹发射时,丝毫没有技术背景的他却赢得了大批专业技术人才的信任和怀念。
这其实是普遍现象。上世纪中情局的若干高科技工程中,主管Parangosky并不是理工科出身,但这不妨碍他受到大家的一致尊重,被公认为“奇迹创造者”(参考《K-129,CIA“偷天换日”的工程奇迹【二】》)。
所有这些例子充分说明,不管是否技术出身的技术领导者,都不必过分强调“技术”,不必强求事无巨细全部掌握。相反,强求“面面俱到”反而显得荒谬。
我曾经写文章介绍过我国著名的理论物理学家束星北教授(参考《看,这就是束星北先生》)。在十年动乱中遭受迫害。有一次,他被要求爬上电线杆去接电线,这种任务实在为难一把年纪的束星北,结果管制他的人反而说起了风凉话:还什么搞物理的大学教授呢,连个电线都不会接……
看看正反两方面的例子,我感到有点惭愧,因为我自己许多做法就是反面典型。比如希望掌握所有细节,不但消耗了自己的精力,也没有给其他人放手工作的信任感;再比如拿细节去要求候选人和其它同事,有时候甚至到了“刁难”的程度,其实并不利于客观判断他们的水平和贡献。
所以在观察、比较、思索了很久之后,我的结论是:技术领导者的精力是有限的,他们的能力模型既不应当是“博而不精”的宽泛,也不应当是“深而不广”的专注,甚至业界流行的“T型人才”也不准确。对技术领导者来说,最合适的能力模型应当是钉耙型。
说到“钉耙”,许多人第一个想到的大概是猪八戒的九齿钉耙,我们就拿九齿钉耙为例。钉耙很宽,扫出去可以覆盖一个面;同时钉耙又有许多齿,可以在某些具体的点上深入。不过无论如何,太上老君只有那么多神镔铁可以用来打造九齿钉耙,在资源有限的情况下就得具体分析,考虑钉耙到底有多宽,有几个齿,每个齿应该有多深。
技术领导者可以动用的全部精力,就是打造钉耙可以用到的全部原料。每一名技术领导者都要思考,这些精力该如何分配,是照顾更宽广的面,还是照顾更深入的点——照顾哪些点、照顾到多深…… 身为技术领导者,重要的不是你永远在每个点上都扎到很深,而是应当具备“无论哪个点上出现问题,需要你的时候都能深入扎进去”的能力。
换句话说,重要的是能及时识别和发现问题,及时了解问题,及时给出靠谱的解决方案。哪怕当时答不上来,但是能通过询问、学习、分析能迅速定位和解决问题,就是合格的技术领导者。
而且与一次成型的钉耙不同,技术领导者必须时常“吊着一股劲”,那就是根据具体情况识别出最重要的问题,据此调整自己的精力分配和能力组成:如果运维弱一点,就要在运维这个点上扎深一点;如果前端弱一点,就得在前端这个点上扎深一点;如果暂时各团队状况都还不错,那就把覆盖面铺更广一点,多为未来做规划……
总这个角度,也就可以理解为什么许多人说领导的关键就在于“找到合适的人,放到合适的位置上”,只有这样,领导者的钉耙才可以铺得很宽,不必在具体的细节上耗费太多。但是,如何找到合适的人,如何放到合适的位置,这恰恰是需要有足够的细节知识才能作出可靠判断的。
总之一句话,各公司的情况不同,同样公司在不同阶段的情况也不同,合格的技术领导者一定需要具备“柔性”素质,能融入百般场景,解决万千问题。
这也解释了为什么许多非技术出身的领导者,也可以做好技术团队的管理。原因大多是他们眼光精准、视野开阔、思维严密,并且对未来有充分的预见,时常能识别出当前最重要、最要紧的问题,投入资源去解决,确保一切处在有序、可控的状态。当然,还少不了对技术人员的尊重,对技术规律的敬畏。
在此之外,技术出身的技术领导者还有额外的优势。他们对基础知识的掌握,对细节的了解,让他们即便面对陌生领域,也能够迅速搭起“从已知到未知”的桥梁,迅速得到“内行人”的视角,迅速和大家找到共同语言。非技术出身的领导者在这方面就要吃力许多,所以也只有少数极高明的人能做得好。
认同这一点,许多问题也豁然开朗了。
身为技术领导者,最重要的是保持对技术的敬畏,以及不排斥谈细节的意愿,所以虚浮的作风是万万要不得的。但同时,也不必苛求自己时刻了解所有细节。
在工作中,我们可以经常询问自己:当前我是不是在解决最要紧的问题?这个问题的背景我是否充分认识了?对于解决方案我是否有足够的了解和把握?我目前没有具体关心的那些问题,是不是有靠谱的团队在用靠谱的方式解决?
如果这些问题的回答都是肯定的,那么即便有一些技术细节不了解也是相当正常的,大可放心继续工作。如果有一个问题的回答不是肯定的,那么工作就还没有做到位,这时候即便你掌握了各种技术细节,大概也不算称职。
对自己是如此,对其他人也是如此。至少在我看来,在招聘技术负责人时,没有必要过分纠结技术细节,而应当侧重考察对方的技术素养,所以重要的不是对细节了解多少,而是工作习惯有多细致。
具体来说,技术细节的问题,大概可以分为三类:
第一类,是候选人自称做过,也着重投入过精力的领域。合格的候选人,对这些细节细节是应当完整掌握的,并且其掌握应当能互相支撑印证,构成完整的技术决策网,不能有“想当然”的环节。如果这个领域的细节答不出来,或者经不住追问,那多半是很有问题的。
比如候选人说自己做过服务治理,那么能谈的不应当只是和流行的PPT一样,大而化之地列举服务治理的好处,几个主要组成部分,还应当清楚服务注册流程、服务生命周期定义、异常(尤其是安全)情况处理、扩缩容规范和限制等细节信息。如果谈不出来,“做过服务治理”的经历就应当打个折扣。
第二类,是候选人没有专门做过,但是不管解决哪个领域的问题都需要具备的基础细节。比如“一个int类型变量占几个字节”的问题就是如此,系统要做复杂一点,在分析和设计的时候,这些知识是不能空缺的。
候选人还应当了解其它的基础细节,比如光在真空中的传输速度是30万公里/秒,而在光纤中的传输速度是20万公里/秒。这样分析技术问题时才有根据,比如北京到上海的直线距离大概是1200公里,所以单程理论传输时间大约要10ms,则ping值在25-30ms左右是正常的,没有更多优化空间优化。但南京到上海的距离只有不到300公里,如果ping值也在30ms,则网络上估计还有些问题。这样的细节知识,就是前端、后端、运维都可以用上的(此处数据经过老高(高春辉)确认)。
第三类,是候选人没有专门做过,但也不那么基础的细节。这类细节如果答不上来,其实并不是很要紧。很难想象做社交的技术人员能懂得音视频处理的细节,做金融的技术人员能懂得游戏开发的细节。
只要职位上升到一定的高度,都不可能在技术细节上面面俱到。就像上文说的,只要候选人有足够的技术素质,在宽度上能覆盖这些领域,能找到靠谱的人、评估出靠谱的方案,或者在深度上能保持(经过一段时间的学习了解)介入能力,这些问题是多半都是可以解决的。
所以我的最终答案就是,“能力上不求全责备,意愿上不推三阻四”。如果面试遇到细节问题,最真诚的答案大概是这样:“我是技术总监,我可以把几个重要领域的细节全部谈清楚,但其它领域的细节我未必知道。不过我通常能判断一个不那么熟悉领域的方案是否靠谱,如果再多给我一点时间,我相信自己能答上来”。