一个技术总监的忠告:你精通那么多技术,为何还是不受重用?

程序视界

共 5139字,需浏览 11分钟

 ·

2021-02-02 04:17

前段时间发了一篇文章——“中年架构师,悲催的一天”,反响蛮多,今天这篇文章,我们继续说架构师大刘的故事。

老田升职了,年薪涨到了百万级别!

这是大刘在加班搞技术攻坚的时候,听别的同事聊了那么一嘴。

大刘心里不是滋味儿。老田和大刘其实在这家公司之前就是同事了,老田能到这家公司,说起来还是大刘推荐的。

但是,在公司的这几年,老田越来越受领导赏识,到如今,晋升成功,赫然成了大刘的上司。大刘百思不得其解。

大刘和老田本身在前家公司都是高级程序员,前后脚跳槽到了现在这家公司。

大刘来的早,成了架构师。老田呢,技术本就不如大刘,被大刘拉来后,先是当了个高级工程师,只是为了避嫌,没跟大刘一个团队。

后来,老田被那时候的 Leader 赏识,做了带项目的组长,再后来,就是现在成功的晋升总监了。而大刘,好几年了却依然在架构师这岗位原地踏步,动弹不得。

大刘陷入了浓浓的迷茫,他自问自己工作态度毫无问题,做事情也兢兢业业。公司的技术攻关,经常也是大刘牵头搞定。公司的技术培训,作为架构师的大刘俨然是一个非常权威的大牛讲师。

就算是老田,也需要时不时去找大刘请教一些技术难题和技术方向。可是,即使这样,在公司技术领域造诣很深的大刘,却依然没有获得进身之阶,被老田压了一头。

大刘没忍住,找了个不忙的日子,拉着老田去了个小饭馆,在饭桌上,大刘就说起了他自己的尴尬处境以及对老田升职加薪的不解。

老田对大刘并没有藏着掖着,在饭桌上,他和大刘坦诚沟通了他的经验,并列出了他认为他可以升职加薪的一些非常突出的能力。

二人酒足饭饱,大刘回到家后,仔细琢磨深究,他总结了以下几点。

1. 尽量努力的多去阅读别人的代码,越多越好

这点大刘开始并没当回事,可是在和老田沟通的过程中,大刘发现,老田理解的阅读别人的代码和他理解的阅读代码是两回事。

大刘阅读代码,特别喜欢看那些开源的好代码。跟着文档品读那些开源的优秀代码的卓越之处,每当看到妙处,大刘都觉得学到了新东西,感觉自己技术进步了许多。

但是,当大刘阅读自己公司的各种代码的时候,大刘是相当没有耐心的。他觉得别人代码写的太次了,他把这些代码统统成为“屎山”。

而老田恰恰相反。老实说,老田对市面上各种开源框架的了解水平,对各种中间件的内部原理理解都是远远不如大刘的,经常还需要咨询大刘。

但是,对于公司的各项目代码,老田却是了如指掌,对各项目中的那些代码和问题都是有十分深入的了解。

那么最终升职加薪不是大刘,这是为什么?

二人聊完之后,大刘终于明白了。

首先,公司除了需要大刘的技术能力,更需要的是作为技术专家解决公司实际问题的能力。

由于大刘抵触阅读公司很多项目的代码,所以,往往大刘的某些技术方案在落地的时候会出现脱节。有时候,又由于对项目代码的不理解,甚至没有给出有效的解决方案。

而老田,由于对公司项目代码了解的很深入,虽然技术能力或者说知识面不如大刘,但是却总是能给出最合理的解决方案来。

长此以往,老田反而比大刘更展示出了一位高级技术人员应该具有的能力。

很多程序员和大刘其实是一样的,他们不喜欢自己公司的很多代码,认为这些代码质量极差,文档也非常欠缺,对自己的成长帮助不大。

其实这个观念其实是很有问题的。

对这些所谓“屎山”的代码,你如果全都读进去,研究下去,你起码会有两个好处:

  1. 你能具体知道代码烂在什么地方,那么以后你的代码就不会出现同样的问题——由于你知道了烂代码烂在哪里,你一定能写出更好的代码,从而让那些屎山的代码逐渐会被自己写的好代码所替代。这样一比较,你的专业能力会显得非常突出,让更多的人认可你这位架构师的能力。

  2. 你对公司这些代码读的越多,掌握的越多,你越不可替代——对公司这些代码读的越通透,你越能更快速轻松地把控这些代码,让以后对这些代码的变革变得更容易。而轻松修改、革新这些代码的能力,就会变成你在这家公司不可替代性的重要因素。

所以,各种代码,无论质量好坏,都需要能读懂读通,并且读的越多越好。

能读懂读通任何质量的代码,才是真正的掌握了阅读代码的能力。读的越多,则能识别代码质量的能力就越强,将来自己就越能写出更好质量的代码。

2. 能准确判断项目的发展方向

大刘和老田谈的时候,让大刘印象最深刻的就是,老田对项目发展状态的精准判断。

三年前,俩人一起搞了个供公司所有业务项目用的监控系统,目的是解决公司项目错误无法及时发现和处理的问题。

当时,这套监控系统公司要的急,大家匆匆设计了一版,就赶紧赶鸭子上架的做了一版。

技术方案也没花太多心思,怎么快怎么来。搞完之后,大刘觉得这项目以后也就这样了,公司内部项目,既没有发展,也没有什么前景。

可是,如今和老田沟通后,大刘才吃惊的发现,老田居然一直跟着这个项目,并对这项目进行了无数次总结分析和优化。

随着不断地改进,这套项目竟然发展出来了一套非常完备的 APM 系统,使用体验非常不错。公司的商务给客户出解决方案的时候,经常也会连带着把这套监控系统包含到解决方案里。客户的反馈也很好,为公司拿下了更多的订单。

而大刘自己呢,为公司的核心系统设计了一套底层的服务调度编排框架,公司很多系统的底层都依赖于这套框架。

虽然这套框架大刘自己认为写的很棒,但是由于部署复杂,对应的一些辅助工具链也由于大刘的忽视,没有及时开发出来。导致后续的新项目,大家宁肯用一些开源框架自己改进,也不再使用大刘的这套框架。

分析起来,其实这也算是大刘和老田对各自项目的发展判断能力的差距导致的。

老田根据用户反馈和市场行情,他感觉监控系统本身应该是有前途的。并在调研了市面上竞对产品的基础上,让这套监控系统迸发出来了绚烂的色彩。

而大刘,高开低走,写出来一个好框架,但是由于对框架的预期判断错误,加上对用户反馈重视不够,最终导致本来应该非常出彩的框架就此沉沦了下去。

3. 去主动管理会议

作为公司比较重要的技术专家,大量的会议是免不了的。

大刘对此非常烦恼,经常因为这些冗长的会议,耽误了许多手头的工作。

特别是,大刘作为架构师,需要大块连续的时间去思考技术难题,解决系统问题,以及考虑新项目的架构设计。但是频繁的会议,把大刘的时间搅和的支离破碎。

对于这个问题,大刘在饭桌上请教了老田。老田说,他也面对了这些问题,好在他通过一些自己的方法,很大程度缓解了这些问题。

老田做了如下几个事情:

  1. 老田对第二天的会议提前和参会各方沟通,开会时间尽量协调到一起,这样老田能腾出一整块儿时间,把当日所有可能的会议都集中开完。后续老田就会有连续的时间去深度工作了。
  2. 老田会在开会前一天,把会议内容和可能出现的问题都预先做功课。一方面是防止会议开着开着跑题;二是万一出现争议问题,老田可以列举出来事先准备的技术方案,这样也能加快会议进度。
  3. 还有,对于一些不那么重要的会议,老田一定会态度坚决的避开或者指派别人参加。

4. 版本控制工具的熟练应用

这个问题是老田主动和大刘提出来的。

老田发现,对于版本工具使用不当,会耽误开发人员很多时间。而版本控制工具,即使一些工作多年的程序员,往往也经常会使用不当。

这些不当的使用,会造成许多问题。比如,各种各样的代码冲突、版本重叠,莫名其妙的代码丢失。

对此,老田每次负责一个新项目,都会严格指定版本工具的使用规范,会花时间对开发人员统一培训版本工具的使用。同时,也会把各种技巧、注意事项、常用命令整理好,放在内部的共享文档中。

老田的这些举措,在实践中,大大改善了版本控制工具不当使用造成的问题。

有一个项目组在规范使用之后,竟然比之前的开发速度快了三分之一。可想而知,这个问题有多严重了。

5. 不要把解决方案复杂化

老田和大刘谈了谈关于技术和技术落地之间存在的问题。

老田和大刘都发现有些程序员特别喜欢炫技,这些炫技某些时候会导致整个系统复杂化,最终产出反而不尽如人意。

老田举了个例子,比如,一套内部使用的资产管理系统,中间有一个需要调用公司其他项目接口的小功能,这种简单的东西交给了一个比较年轻的程序员。

结果这个程序员又是考虑对方接口不稳定的情况,又是考虑这个功能会有使用过度频繁的情况,还使用了缓存去储存一些状态,防止频繁调用数据库。

对于这种情况,从纯技术角度,当然会鼓励人们想的越全面越好。但是,在实际落地的时候,你要明白这只是一个公司内部使用的小项目,没必要为了各种概率很低的风险,把明明很小的一个功能给做的很复杂。

针对这种问题,就需要技术 Leader 及早发现、介入,防止出现过度设计、过度开发。

6. 把任务安排的井井有条

老田其实和大刘一样,每天杂事儿很多,每天的任务也很多。大家对这些任务的管理能力自然就有高有低。

老田对于任务紧急程度的判断都是经过深思熟虑、实际分析过的,任务之间的先后顺序,也和任务交付人认真沟通过。对一些根本没必要的任务,老田会态度坚决的对这些任务说 No。

大刘自我总结,他这方面做的不好。首先,他安排任务容易被任务交付人的情绪影响,对方催的急,他就优先安排。其次,任何任务大刘都没有拒绝过,顶多是排期靠后。最后,大刘没有考虑任务和任务之间的关系,有些任务之间是关联的,完全可以融合一起搞定,大刘却没有思考,从而割裂开安排,这也是很大的问题。

比如上次,大刘接到两个任务:1、去掉 VMware;2、MQ 版本升级。

这两个任务都需要业务系统停服才能干,大刘当时也没在意,两个任务放在两天,连续两天停服,虽说每天停的时间不长吧……

这俩任务完全可以放在一起,利用一次停服集中解决。这样对用户影响更小,业务部门也不会那么不满。

7. 不要死板的写代码

很多程序员知识面很宽,基本功也非常扎实。但是,有一种能力,是学校教不出来、面试也不容易看出来的,就是代码能力。

所谓的代码能力,有的是指写代码不出 Bug 的能力,有的是指算法落地能力……但这里想说的,是不写死板的呆代码的能力。

这是什么意思呢?

我们都知道,程序员少不了要维护老项目。在维护项目的时候,我们面对各种不断的新需求,经常要去修改代码。

修改代码是个很危险的事情,因为我们修改的代码往往会和别的功能耦合住。改了一点代码,结果影响一大片功能的情况经常出现。最虐心的是,这种连带影响可能不会马上出现,不知道哪天就突然冒出来折腾一把。

如果改代码经常出问题,这谁扛得住啊!别说你自己的技术话语权了,也别说在职场脱颖而出了,工作能不能保得住都不好说。

所以,对于修改代码的事情,我们需要学会的是不要写呆代码。再说的直白点就是,你不能写完代码运行下没问题就觉得正常了,你在写代码之前需要好好思考。

这种思考,既不是什么搞设计模式松耦合,也不是搞功能切分独立成块。这种思考本质是需要你写代码前去理解业务,去真正明白业务在实际是怎么运作的。

简单说两个例子:

7.1. 修改完代码后,用户会怎么使用你现在修改的功能?

比如,你修改了注册功能,可以兼容第三方登录。那么,可能有的老用户会重新注册一个账号,以方便第三方登录。那你对这种情况,其实该做的是绑定,而不是让用户重新注册个新账号。

这种疏漏,等到上线之后才发现就晚了。这不能完全依赖产品经理,作为一个技术人员本来就应该对自己的功能做通盘的考虑,这才是真正的负责。

7.2. 你现在修改的功能,会不会由于运营需要,会换成你完全没想过的用法?

比如,你搞一个用户充值功能。本来你只是想着用户游戏内购直接充值即可。但是,在实际上线后,有时候运营为了方便 vip 客户或者为了和第三方渠道互换资源,也会使用这个充值功能。

运营大批量的连续充值,并且这些充值转换成系统中的货币,就像游戏中的元宝,就有可能超出 Java 中的整数上限,从而造成问题。如果你提前知道用户、运营人员都是怎么使用这个功能的,你就会把数据类型修改成 Long 了。

类似的例子有很多,老田还要继续说下去的时候,大刘给他打断了,“扎心了,你说这些坑我没少掉进去。”

后记

通过和老田沟通,大刘知道自己的问题出在哪了。他明白了,技术只是技术人员的基础,在实际工作中想脱颖而出,除了要有过硬的技术,还需要你的态度、你的各种软实力,需要你把技术转化为实际生产力的能力。
大刘的故事这次先说到这里。

上次故事回顾:中年架构师,悲催的一天


推荐阅读

从手握钢钳的牙医到名满世界的作家

外企年薪60万 vs 互联网公司年薪90万
那些比“工资低”更危险的事
工作不开心想辞职可又不知道做什么
能出奇迹的职场笨策略
欢迎添加安晓辉老师微信a32352937
一对一咨询识别上图二维码
文字咨询请戳阅读原文
浏览 47
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报