挺久时间没有更新了,最近脑海中有几个化为文字的想法,但是都比较散,也就没有落笔。不过忽然有一个念头冒了出来,就是这些想法里面,有几个其实都是关于软件工程师成长的一个 “误区”。可以说,从 2008 年步入职场以来,这个误区导致的坑,或早或晚我踩过不少,我觉得把它们总结一下,写出来,兴许能给一些朋友们带来一点帮助。
“我对技术感兴趣,我只想做技术,走技术路线。”
这句话是不是很听过呢?请不要误会,这句话本身没有问题,但是说出这句话的软件工程师中,十有八九有一个误区,就是高估了技术本身在个人职业生涯中,起作用的占比。而我,曾经是其中之一。
我多次听到来自家长这样的评论,说是他/她的孩子不善言辞,缺乏沟通技巧,然而罗辑思维缜密,对于软件技术充满热情,想做一个出色的程序员。
我觉得,这样的言论,既对又不对。对的是,如果刚踏入职场,相当一个优秀的程序员,我觉得上述的优缺点,都很 “契合”,或者说,也许只需要学好技术,把确定的任务做完、做好,就能找得到工作的褒奖,就能胜任岗位。但是,随着你继续在职业生涯的道路上向上突破,基本坚定地走着技术通道(譬如我),上述能力的缺失,而造成的 “短板效应”,会越来越明显。
个中的原因,其实并不难理解。软件工程师,不是搞学术,而是搞工程,而工程能力,是一个非常复杂的多面体。比如提到的沟通合作的能力,是根本就绕不过去的。职场这些年来,我已经无数次看到那些所谓的技术 “牛人”,有着优秀的独立问题分析与解决的技能,却总是在贡献与晋升方面迟人一步,甚至多年过去,也难以在职业生涯的路线上,迈入更高的台阶。
除了沟通,再举一个例子,管理能力。我知道很多铁了心要做技术的程序员,也包括曾经的我在内,是对 “管理” 这个词有着不由自主的排斥。总对公司那些技术优秀的工程师,却 “转管理” 嗤之以鼻。某些总失偏颇的媒体也报道,“国外”(他们口中,中国以外的世界仿佛没有太大的分别,统一以 “国外” 概括之)五十岁的工程师还在写代码,六十岁的程序员还在发光发热……我理解这样的想法,但是这里被忽略掉的一个事实是,即便在那样技术通道被极大地保护的环境里,即便继续走坚持技术路线,坚持写代码,随着职位的升高,管理的工作就是不可避免地越来越多的,这是软件之所以为 “工程”、而非 “工学” 的一个特性。
换言之,“沟通” 也好,“管理” 也罢,即便对于技术人来说,也都是逃不掉的。你要跨团队合作,你要带着一票人一起攻克项目,团队能达成的事情,在重要性上往往要盖过自己在努力啃着的特定的问题。
当然,工程这个多面体中,除了 “硬技术”,必备的 “软能力” 有很多,我只是拿这两个方面举了例子。那么,再说一条我认为比较重要的能力吧——对于实际问题、模糊问题的挖掘和剖析能力。
事实上,这一条也是我参与的软件工程师面试中,非常重要的一条考察项。实际问题总是模糊的,先要把问题搞清楚,抽象成一个软件可解的问题,再使用各种软件的工具(代码)来解决问题。
你看,这里面有两个步骤,而在我们所熟悉的教育体系中,后者被极大地强化——算法、数据结构、库、平台……这些涉及的技能领域,都在后者这个 “解决一个已经经过抽象了的问题” 上面;而对于前一步骤的学习,往往是不足的。
什么才是 “模糊的实际问题”?随便举个例子:
我们公司内部有大约 100 个服务(service),提供不同的功能,分别由不同团队维护。现在需要你带领一个小团队,来设计实现一套监控系统,统一监控管理这些服务的健康状况。你打算怎么做?
这就是一个非常模糊的实际问题,不是一个算法问题,也不是一个传统意义上的系统设计问题。但这是一个真正的、实际的 “软件问题”。
最后,我想说的是。日常的工作中,也许我们一猛子下去扎得很深,但是我们还是需要时不时地跳出每天琐碎的条条框框,站高一点审视一下,自己在职业生涯路线中的位置,尽量带着技术人的决心和热情,但不要带着技术人的封闭与迂腐。
文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》
对于模糊的实际问题解决,有什么道道可以遵循吗? 或者说有哪些方面可以提升自己的能力,或者有没有专门研究这方面的学科和结论,有什么的推荐的吗
不给自己设限。