技术能力不等同于工作能力

技术能力不等同于工作能力

前言    

        这篇总结是我在实际工作中的一些心得体会。主要是我在工作中犯的错误然后进行总结,也是对自己的警示。我在这里先抛出一个观点:技术能力不等同于工作能力,只能说技术能力是工作能力的一部分,在公司里会发现有些技术不错的程序员并不得志,有些技术不如他的反而得到晋升。技术能力是工具,是一把刀,是一项很重要的技能,但是如何用好他就看每个人的功力。如果你有杀牛的本领,每天杀鸡有什么用,所以就是如何想方设法的把那项技能给用出来。下面的一些案例可能会有一些体会。


案例一

       事件的背景是我在一个小组周会上进行了一个项目经验的分享,准备上也有些仓促,大概两三个小时写了一个简单的PPT。讲完后就被主管批。他说:“ 在用语言描述项目的时候一定要用技术性的语言进行分析:你为什么做这个项目”。对于这句话我想很多人都不明白什么意思。这里的关键词是" 技术性的语言"这六个字。这里我举一个我在PPT中描述的语言大家就会明白问题出在哪里:"之前大部分依赖于数据库,对于数据库的压力 相对较大。目前在DB前面用缓存挡了一层,对数据库的压力 减少许多。"这里注意一下我在上面一句话中标红的那几个词。这种词是严禁在项目总结中出现,什么叫相对较大,什么叫减少许多,一切都要以 具体的数据说话。相对较大之前的数据性能情况是多少,数据拿出来。你做了改动之后具体的数据是多少,拿出来。这前前后做一个对比,很容易就得出你做这件事的意义是什么。在这个项目中你具体做了哪些改进,而不是简简的说加了一层缓存,这样谁也不明白,你的缓存加在哪里了,是怎么实现的没有说。我刚才的问题一说出来大家都明白,具体实施的时候很多人都会犯这样的毛病。

案例二

       这个案例是上面那个案例接下来的一件事。我对于一个具体的实现发起了一个讨论。先上一张图:
      
         在周会上分享的原图我做了一些修改,这不影响接下来的分析。可能这里很多人不明白我的图。这里我先解释一下: 这其实就是一个把缓存放到服务端还是放到客户端的问题。大家都知道远程通信都需要走网络,有网络IO的开销。我上面所标识的Memcache可以想像成集中式缓存(比如说 Memcached,下面我都以 Memcached来写,这样可以和本地缓存区分开), Memcached通信也需要走网络IO。我们原先的设计就是把读写 Memcached放到 服务A,这样就会至少产生两次IO,如果缓存失效,走DB的话最多会有三次IO, 但是在应用端加一个本地缓存。我的观点是把本地缓存去掉,然后把读 Memcached放到客户端,这样大部分情况下只有走缓存这样一次IO,对服务器的压力也减少很多。当然在会上我的观点并没有表达的很清楚。另外我这里有一个错误的观点就是 我觉得应该去掉本地缓存去掉。我认为在这里本地缓存是不需要的。这样一种观点首先抛出来是毫无意义的,因为要不要本地缓存到底取决于具体的应用场景,而不能简单的下结论,这个问题我并没有全方位的去想。(关于性能方面可以参考《 性能调优思考》)
         其实在案例二中我所犯的错误一案例一中犯的错误有些类似,如果说把读memcached移到Client端去做还有些说服力,那么去掉本地缓存就毫无说服力,因为我没有任何的数据根据,只是根据一些臆测来进行。另外在整个讨论中我的思路混乱,这也是没有想清楚导致的。所以能不能全方位的思考一个问题也是一个人重要的能力。

案例三

        这是一个项目中的一个案例,在提测的过程中竟然发现主功能有严重的bug。这样的bug被测试发现确实非常惭愧,我把自己骂了好几遍。可能每个人都会为自己辩解,谁写代码没有问题。但是我在这里说一下我自己的体会:一般来讲写代码“ 一遍率(PS:整个逻辑盲写,不做测试)”比较高的同学往往自信心比较高,因为他对自己的代码有信心。而经常写出来代码有问题的程序员可能会 心虚,即使你后面不管是自测还是靠测试把问题测出来,测出的bug越多,对于自己的打击越大。特别是一些严重依赖于开发质量的项目,这样会承受比较大的心理压力。后果是什么?有一点小的改动就会畏首畏尾,不敢改。但是真正要做到细致,以我个人的体会来看,确实很难。
        另外一个就是千万在写代码之前把整个的逻辑细细的想清楚,磨刀不误砍柴工,真理。因为前期没做好的后果就是后面一直在改代码。这样浪费了更多的时间。其实这是一种 思维的转变,很多人也包括我也认同一种观点: 代码是写出来的,即使前期想的再清楚,也会有遗漏。但是在工作中这是一种不太好的实践。要慢慢的学会在前期做更多的工作,后期少的改动。这是一种功力,真的很考验人。对于已经习惯这种思维的人可能不太难。但是如果习惯了在写代码中思考的程序员来说一定要力求改变,在这里也是在警告我自己。
        这里简单的说一下为什么?道理很简单,如果你是在写代码的时候进行思考说明是你喜欢 发现问题解决问题的方式,这是一种 被动的思维方式。这种思维方式可能做一个程序员不会犯太大的错误,至多自己多加一些班。但是如果是一个项目的owner,这样极有可能犯重大错误,整个项目到后期发现方案不可行,这是要命的。 千万不要觉得这紧紧是一种工作方式的问题,这是思维方式的问题。要慢慢的锻炼自己在前期思维能力,就是主动思考,主动发现问题,这样才可能把项目风险掌握在自己的手中。项目实践有一句话:“ 有可能发生但是没有发生的问题叫风险,如果问题已经发生,那就是真的问题”。
       改变思维方式真的很难, 要打破重来很痛苦,绝不会在我这里写出来这么简单,所以为什么我觉得 成功学看的热血沸腾,发现自己一去做完全是两回事。一个简单的习惯都很难改变,何况是对于一种已经几十年的思维习惯。这里我举一种思维实践,仅供参考。脑子里想一个问题,反复的想,把它想的非常透彻,然后把这个问题抛出来,看看大家都对这个问题的看法,再比对自己有哪些遗漏。这一方面是思维的过程,另一方面也算是经验积累的过程。因为很多问题想多了考虑的面自然就会丰富起来。

总结

       上面讲了三个案例对于我在工作中的一些心得体会,这里面和技术没有太大的关系。我在前言中也说到了技术能力不等同于工作能力。这里可能很多人不认同,没有关系,观点可以求同存异。很多人可以从跳槽中获得薪资的提升,而公司内部的晋升确很难(这里不讨论公司等客观原因)。因为在面试的过程中大部分只会考一些技术问题。而在工作中更多的是一个人的综合能力,而这是简单的一些面试得不出来的。很多人尝到这种甜头就会一直依赖于这种跳槽来获得薪资的提升,然而更重要的是工作能力的提升,工作能力的体现就是绩效KPI。公司永远看绩效,技术再好,结果不好枉然。这里又要叨一些玄话:以结果论英雄是公司的生存法则,也是个人的生存法则,过程是你自己的事情,对于公司而言只关心结果。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值