- 拿到开发任务后,直接上手写代码。缺少必要的沟通与设计,返工的机率极大。前后端数据的交互格式,功能潜在的关联点不清晰,接口调用方功能是否完备,存储结构的设计,复杂业务的流程设计等等,都需要事先沟通确定好,再动手写代码才能游刃有余,不然会走一步卡一步,进展缓慢,甚至倒退。
- 在逻辑混乱的地方加入新东西,而不是去重构。由于功能的新增或变更,需要在旧有的代码逻辑中添加新功能,本是一个很好的重构机会,但很多的做法时在原有的基础上填填补补,结果一片混乱。特别是在本已混乱的地方还要加入新代码逻辑,运行起来确实没有问题,但对自身代码质量的保证零意义。
- 不愿意与别人分享技术成长。教是学习最快的一条路,将自己所学传播分享给他人,并使他人能消化吸收,是对自己知识掌握一个最好的检验。同时在分享的过程中温故而知新,更加深对知识技能的掌握。如果你有教会徒弟饿死师傅的想法,会显得很落伍。互联网时代下,还有什么知识技能,是你独有而别人从来没有的?不如拿出来分享,大家共同成长。一个人走的快,一群人才走的远。
- 遇到BUG首先否定是自己的问题。这是一个普适性的问题,也是程序员遇到BUG时的第一反应。到底是不是别人的问题呢,往往是问题转了一圈又回到自己手里。耽误了大家的时间,同时降低的解决问题的效率。正解的姿势应该是立即检查自身,确定是不是自己的问题,是就立即改正,若不是,能找到问题所在最好,交由他人去处理,这是一种良好的习惯。
- 缺乏验证条件时,开发的功能不经测试直接交付给测试人员。一种是过于自信的表现,还有一种是懒惰的表现。有自信是好的,但如果能经过实际的场景来检验,双重保险,对自己对团队都是保证。懒惰就是不负责任的表现,有些功能确实测试起来很复杂,但为了保证功能的可用性,没有条件去创造条件也要完成,这也是一种态度。
- 修复某BUG时,夹带其它问题。一个未被测试人员发现的BUG,自我发现后私自修复,并提交源码。这在测试阶段比较常见,但后期如果还出现这种问题,对产品/项目的稳定性是个极大的隐患,特别是生产环境。这是一个流程规范问题,也是一个职业素养问题。
- 领导安排什么就做什么,做完了就闲着,也不学习新业务新技能。闲下来就刷刷微博朋友圈,看看新闻聊聊天,这是典型的打工者思维,上班工作,某种意义上也是自己创业的过程,在公司的体系下,利用对应的资源来达成自己的目标,本质上与自己出来创业完成某个目标,路径是差不多的。在别人现有的环境里,不能以自己创业心态来待人接物,简单就是一个浪费,这是一个很好锻炼的机会,主动去承担更大的责任,更多的任务。诚然,做的多,出错的概率会更大,但试错的成本很低,成长的机会也更多,没有什么能比成长更好的啦!
- 任务有交叉时,只关注自己的,不能从上下游全局统筹。这其实是个合作意识的问题,需要双方或多方都比较爽才行,而不是只让自己爽,让别人很别扭。久而久之,自己会被孤立,这不是单次博弈,而是重复博弈,最优策略就是共赢。
- 自己做的比较快,但旁边的兄弟任务似乎比较重,而自己又不施与援手。个体技能的不同必然导致结果差异,但对于团队而言,需要的不仅仅是个体的成绩,而是团队的协作产生的高效率、高质量。这也是一个重复博弈的过程,难保自己有遇到困难的时候,你难道不希望有人搭把手共同解决问题?人同此心,心同此理,相互扶持,这是团队作战的魅力。
- 不及时反馈工作进展。做事最忌讳的就是虎头蛇尾,多数情况下会无疾而终,不了了之。对于被指派的任务最好的做法是及时上报风险、暴露困难,及时汇报进度,这样即便是达不到工作目标,整个过程也是有目共睹的。领导最怕的做法就是任务下发后,下面的也保证完成任务,但真到交活了,摆出一堆这样那样的理由,任务就是没有完成。当你没有把握给领导惊喜的时候,及时汇报工作进度,免得到最后只有惊吓,为时晚矣。
- 伸手党。到论坛里、社群里随便一看就能抓出来一堆,目的就是为了更快达成目标,但又能力不足或偷懒,而完全依赖于他人,最好是他把需求一提,你把交付物一给就算完事。还有一种情况,出现问题后,不经深入分析,直接找别人来解决。长期伸手而不真正上手操练,业务能力自然下降,只能自尝苦果。有句话讲:你可以像只猪一样懒,却无法像只猪一样,懒得心安理得。这才是痛点。
- 课余时间不充电。下班后基本处于散养状态,工作基本吃老本,或者勉强能对付,工作上基本没什么大起色,不算差但也不算好。之前讲“你只有不停的奔跑,才能停留在原地!”,凸显出时代的变化之块,不是大鱼小鱼,而是快鱼吃慢鱼,特别在一些生活、工作节奏都比较慢的二三线城市。人与人之间的差距并不是在工作八小时内拉开的,起决定作用的而是工作之外,所谓工夫在诗外。技术更新迭代的速度远超任何一个时代,比我们优秀的人还在拼命,我们又有什么理由懒惰呢?
- 不能主动推动事物前进。 主动做一件事跟被动接受去做事,心情都是不一样的,做事效率更是千差万别。主动的人有更多的成长机会,反之在被动中不断的响应别人的任务,这与处于那个层次高低无关。如果处于高层级却不能主动推进任务前进,相信在这个岗位上也不会呆太久。
- 技术交流分享会仅仅是听听而已。 在一线城市这种机会特别多,如果你愿意,一天可以赶好几场。虽说是别人分享,如果没有好好利用,仅仅参加完就离开的话,效果几乎为零。可以事先熟悉讲师履历、分享的内容,带着自己的疑问听,不懂处记录在册,答疑环节将疑问点抛出,多认识些分享会上的人,加入分享会微信群会后继续讨论等等,都能更好的发挥一次分享会的效能。不要让参加技术分享会流于形式。
- 无法多场景切换角色。 刚入门时,醉心于开发还是有可能的,随着年限的增加,个人职责会发生改变,再有整块整块的时间去专心某一事务的机会不多,更多的是碎片化的时间切片,面对不同同事、客户、领导、合作伙伴等等,如果不能快速响应各种变化,只能用疲于奔命应付来形容了,工作的条理性更无从谈起。你需要快速切换角色,融入不同环境,能抽象,也能具化,能全局把握,也能细节深入,这样处理起问题才能得心应手,迅速成长。
- 容易陷入细节。 或者说很纠结细节问题,相对的另一面会导致全局观缺失,偶尔还会钻牛角尖。过于追求细节完美的人,也就是完美主义者,事实时完美在现实生活中不可能存在。陷入细节而不自知轻则项目延期,重则错过市场窗口期。把握一个度很重要,需要以大局为重时,就需要牺牲局部的不完善。
- 不插手开发任务外的其他事务。临时任务在所难免,特别是创业团队,更是没有明确界线的岗位分工,需要时,直接顶上,目标就是把事情做成。仅关注开发任务那点事,显然不足以为更高的岗位做技能储备,如果力所能及又不占用过多时间的话,建议去锻炼一下。经历都算自己的,成长过,谁也拿不走。
- 不注重关键节点的记录留存。 人员流动、业务变更对软件后续的维护都是挑战,仅靠脑袋记,显然不现实。很多朋友说,代码里都有啊,看代码就行了。如果必须拿代码才能说事的话,只能说你太不成熟,设计文档、流程图、数据表格这些辅助理解的东西简直难道是摆设?特别是一些复杂的业务流程设计、复杂算法设计、疑难BUG解决方案等等。虽然敏捷开发不主张凡事以文档必备为准,但必要的文档留存很重要,形式可以不限。
- 不愿意跟领导走的近。 是不是有这样的体会:凡事有领导在的场合,气氛都比较凝重?整个人都放不开?其实这还是一个雇佣关系在作怪。员工与领导并不是处于一个合作互利互惠状态,也就是《联盟》一书中讲到的合作关系。如果还没看过的话,建议你去买来读一读。跟领导走的近有什么坏处吗?不能偷懒了是真的。在我看来,跟高管成为朋友是对职业生涯有益的事情。可以让领导更深入的了解你,可以站在比自己更高的维度去待人接物,可以接触到很多更高层次的人脉等等等等等,还有很多,待你去发掘。如果有机会,千万不要躲的远远的。
- 缺乏理财意识。 IT人薪资水平较一般行业而言还是比较可观的,但如果不注意保值、增值的话,月光是完全存在的,加上信用消费如此普及,卡里的数字会只减不增。再加上通胀,仅靠储蓄的话,实际上是资产贬值的过程。如此聪明的脑袋瓜,去接触一些股票、债券、基金、P2P、房产等标的的投资操作,还是很有必要的,你想实现财务自由吗?那就去提高你的睡后收入[被动收入]吧。
- 频繁的变换行业。 信息化的触角已深入到各行各业,但行业与行业间的业务差别很大,而且有些行业的壁垒高、专业性很强,比如医药、财务等。技术服务于业务,如果你的适应性很强,融会贯通的能力很强倒也无妨,但大部分情况下是刚接触一个还没深入就结束了,如果不能保持连贯,很可能到此就结束了。实际业务运行过程中的核心点需要一定的积累才能掌握,这就需要在行业里沉淀多年才能达到,比如专注金融行业,但里面也会涉及保险、证券、银行等几种业务场景,每一种又是繁杂多变,如果频繁变换从事的行业,基本上谈不上沉淀,随着工作年限的增长,自己的竞争力却没有提到提升,错失成为业务专家的能力。
- 不停追逐新技术,由于不能应用于实际工作,导致很快被遗忘。 技术更新迭代的速度远非一个人穷一生之力所能学完的,所谓以有限的生命去掌握无限的技能仅仅是美好的事,但不现实。考虑到具体的技术成熟度、应用场景与自己的工作实践的匹配度,只能是那些切实应用于实践的技术栈才能更快更深的掌握住。具体到自己的职业规划中,更应当聚焦,找准一个点,基于这个点再外延,打造自己的技术生态圈。切忌把自己打造成一个掌握很多技术但无关度很高的瑞士军刀,其竞争力远不如一技之长。
- 与他人沟通不畅时,不能本着解决问题的思想来解决问题。 “好,好,好,不说了,打住,我不跟你争了,就按你说的来,有问题你负责”。如果是本着解决问题的目标去解决问题,我们可以摆事实,讲论据,把各种方案存在的利弊得失放在明面上,然后大家再客观的就事论事,拿出一致的解决方案。你会时常碰到一些人在讨论问题时,最后的结果是一方不愿意再争论而妥协,但并非心服口服的妥协,这是直接撂挑子,而不是解决问题。
- 跟踪问题不彻底,导致前功尽弃。如果别人欠一大笔钱,想必你无论如何都会想尽一切办法,把这笔钱追要回来。很可惜的是,在日常的工作中,我们跟踪一个任务的时候却远不如追账那么用心,跟着跟着然后就没然后了。可想而知,如果都这种状态的话,你的项目进度,你的销售目标,你的市场份额如何达成,试想有一天你成高层领导,你手下的兄弟都是这个状态跟踪问题,那你真的是得操碎了心也搞不定。
- 不依规范行事。 这个很常见,嘴上一套,行动时另一套,也就是知行不一。实际是知易行难,不自我监督,不自我约束,整个人都会变的懒散。“这个版本着急上线,先把功能实现再说,后面有时间再来重构优化”,是不是经常听到这样的套路,他们事后有重构吗?你自己事后有去看看哪些糟糕的代码吗?如果事出紧急事后完善也是允许的,就怕是个幌子,事后弃之九霄云外。
- 想做却迟迟不行动。 非得万事俱备了才行动,其实很多时永远没有完备的时候,先动起来再说,再行动的过程中肯定会遇到问题,去解决就是了。否则有的只是眼前的苟且,不会有诗和远方。“成功学”里讲,想成功与要成功是两回事,虽然是一字之差。
- 不能虚心学习别人的长处。 都说文人相轻,其实IT界也有一条鄙视链,我们也总在有意无意见践行着这条鄙视链。即便是同一条链上的蚂蚱也存在相互不顺眼的时刻。但学习这东西,要虚心,不能说你看不惯他,就拒绝他身上一切事物,那怕是好的,这真的是跟自己过不去。你有看不惯的人吗?你发现他身上有你不具备的东西吗?
- 会很多开发语言但不都精通。 不排除大牛做的到,一般人的话,你这么写简历,还真不会让人高看一眼,很容易给别人留下一个什么都会,基本上又什么都不会的印象。不要追逐新技术,技术迭代的速度远比你学习的速度快的多,求多往往会不深入,止于皮毛,而一个技术的应用绝不是写个“hello world”就算的,应用到实际业务场景,解决实际的需求痛点才能发挥一项技术的本真。
- 软件研发技能单一。 软件生命周期里除了编码实现,还有需求分析、系统设计、测试部署、发布上线、运维运营等等,只盯着代码那一块太狭隘,特别是工作时间长了之后,局限性会越来越明显。开发语言是工具,不用锤子用榔头一样敲东西。要提高自己的适应性,就得外延技能线,后面的职业路也会更宽广,而不是局限在技术一条线。追求全栈没有错,但要适度,不能盲目的为了简历上几行字,去涉猎那些看似有用,但实际并不会使用的技术。
- 缺乏危机意识。 去年的热点话题事件就是中兴的一位40多岁的IT人自杀。雪球上针对这一问题爆发了“中年危机”的大讨论。中年危机是八零后绕不开的一个问题,张爱玲在《半生缘》里说,“中年以后的男人,时常会觉得孤独,因为他一睁开眼睛,周围都是要依靠他的人,却没有他可以依靠的人。”手机屏幕前的你考虑过这个问题吗?
会阻碍程序员成长的细节
最新推荐文章于 2023-03-28 08:44:35 发布