|
|
51CTO旗下网站
|
|
移动端

我是技术总监,我确实答不出那么多技术细节!

前段时间,朋友圈被《我是技术总监,你干嘛总问我技术细节》刷屏了,微信群里也有不少讨论。

作者:余晟来源:余晟以为|2019-06-24 08:32

前段时间,朋友圈被《我是技术总监,你干嘛总问我技术细节》刷屏了,微信群里也有不少讨论。

就我所看到的情况,各种意见都有:

  • 有人认为“技术人不能丢掉技术”。
  • 也有人认为“工作做到上面都是考验人性”。
  • 还有人认为“工种不同,技术细节不清楚很正常”。

借这个机会,我想谈谈自己的经历。十多年前,我曾经去 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,则网络上估计还有些问题。

这样的细节知识,就是前端、后端、运维都可以用上的(此处数据经过老高(高春辉)确认)。

第三类,是候选人没有专门做过,但也不那么基础的细节。这类细节如果答不上来,其实并不是很要紧。

很难想象做社交的技术人员能懂得音视频处理的细节,做金融的技术人员能懂得游戏开发的细节。只要职位上升到一定的高度,都不可能在技术细节上面面俱到。

就像上文说的,只要候选人有足够的技术素质,在宽度上能覆盖这些领域,能找到靠谱的人、评估出靠谱的方案,或者在深度上能保持(经过一段时间的学习了解)介入能力,这些问题多半都是可以解决的。

所以我的最终答案就是,“能力上不求全责备,意愿上不推三阻四”。

如果面试遇到细节问题,最真诚的答案大概是这样:“我是技术总监,我可以把几个重要领域的细节全部谈清楚,但其他领域的细节我未必知道。不过我通常能判断一个不那么熟悉领域的方案是否靠谱,如果再多给我一点时间,我相信自己能答上来”。

【编辑推荐】

  1. 融合八大前沿技术 PTC Creo 6.0掀起设计复兴潮
  2. Slack 进入微软内部禁用服务清单,GitHub 也在其列?
  3. 盖茨:最大的失误是没能做好手机系统对抗苹果
  4. 5G时代,WiFi是被淘汰,还是变得更强大?
  5. 台积电首秀自研ARM芯片:7nm工艺、 4核A72频率高达4GHz
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

这就是5G

这就是5G

5G那些事儿
共15章 | armmay

115人订阅学习

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

371人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

758人订阅学习

读 书 +更多

Grails权威指南

本书译自Grails项目负责人Graeme Keith Rocher所著的“The Definitive Guide to Grails”一书,着重介绍了如何在Grails框架下使用Groovy语...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微