那些会阻碍程序员成长的细节

拿到开发任务后,直接上手写代码。缺少必要的沟通与设计,返工的机率极大。前后端数据的交互格式,功能潜在的关联点不清晰,接口调用方功能是否完备,存储结构的设计,复杂业务的流程设计等等,都需要事先沟通确定好,再动手写代码才能游刃有余,不然会走一步卡一步,进展缓慢,甚至倒退。

在逻辑混乱的地方加入新东西,而不是去重构。由于功能的新增或变更,需要在旧有的代码逻辑中添加新功能,本是一个很好的重构机会,但很多的做法时在原有的基础上填填补补,结果一片混乱。特别是在本已混乱的地方还要加入新代码逻辑,运行起来确实没有问题,但对自身代码质量的保证零意义。

不愿意与别人分享技术成长。教是学习最快的一条路,将自己所学传播分享给他人,并使他人能消化吸收,是对自己知识掌握一个最好的检验。同时在分享的过程中温故而知新,更加深对知识技能的掌握。如果你有教会徒弟饿死师傅的想法,会显得很落伍。互联网时代下,还有什么知识技能,是你独有而别人从来没有的?不如拿出来分享,大家共同成长。一个人走的快,一群人才走的远。

遇到BUG首先否定是自己的问题。这是一个普适性的问题,也是程序员遇到BUG时的第一反应。到底是不是别人的问题呢,往往是问题转了一圈又回到自己手里。耽误了大家的时间,同时降低的解决问题的效率。正解的姿势应该是立即检查自身,确定是不是自己的问题,是就立即改正,若不是,能找到问题所在最好,交由他人去处理,这是一种良好的习惯。

缺乏验证条件时,开发的功能不经测试直接交付给测试人员。一种是过于自信的表现,还有一种是懒惰的表现。有自信是好的,但如果能经过实际的场景来检验,双重保险,对自己对团队都是保证。懒惰就是不负责任的表现,有些功能确实测试起来很复杂,但为了保证功能的可用性,没有条件去创造条件也要完成,这也是一种态度。

修复某BUG时,夹带其它问题。一个未被测试人员发现的BUG,自我发现后私自修复,并提交源码。这在测试阶段比较常见,但后期如果还出现这种问题,对产品/项目的稳定性是个极大的隐患,特别是生产环境。这是一个流程规范问题,也是一个职业素养问题。

领导安排什么就做什么,做完了就闲着,也不学习新业务新技能。闲下来就刷刷微博朋友圈,看看新闻聊聊天,这是典型的打工者思维,上班工作,某种意义上也是自己创业的过程,在公司的体系下,利用对应的资源来达成自己的目标,本质上与自己出来创业完成某个目标,路径是差不多的。在别人现有的环境里,不能以自己创业心态来待人接物,简单就是一个浪费,这是一个很好锻炼的机会,主动去承担更大的责任,更多的任务。诚然,做的多,出错的概率会更大,但试错的成本很低,成长的机会也更多,没有什么能比成长更好的啦!

任务有交叉时,只关注自己的,不能从上下游全局统筹。这其实是个合作意识的问题,需要双方或多方都比较爽才行,而不是只让自己爽,让别人很别扭。久而久之,自己会被孤立,这不是单次博弈,而是重复博弈,最优策略就是共赢。

自己做的比较快,但旁边的兄弟任务似乎比较重,而自己又不施与援手。个体技能的不同必然导致结果差异,但对于团队而言,需要的不仅仅是个体的成绩,而是团队的协作产生的高效率、高质量。这也是一个重复博弈的过程,难保自己有遇到困难的时候,你难道不希望有人搭把手共同解决问题?人同此心,心同此理,相互扶持,这是团队作战的魅力。

不及时反馈工作进展。做事最忌讳的就是虎头蛇尾,多数情况下会无疾而终,不了了之。对于被指派的任务最好的做法是及时上报风险、暴露困难,及时汇报进度,这样即便是达不到工作目标,整个过程也是有目共睹的。领导最怕的做法就是任务下发后,下面的也保证完成任务,但真到交活了,摆出一堆这样那样的理由,任务就是没有完成。当你没有把握给领导惊喜的时候,及时汇报工作进度,免得到最后只有惊吓,为时晚矣。

伸手党。到论坛里、社群里随便一看就能抓出来一堆,目的就是为了更快达成目标,但又能力不足或偷懒,而完全依赖于他人,最好是他把需求一提,你把交付物一给就算完事。还有一种情况,出现问题后,不经深入分析,直接找别人来解决。长期伸手而不真正上手操练,业务能力自然下降,只能自尝苦果。有句话讲:你可以像只猪一样懒,却无法像只猪一样,懒得心安理得。这才是痛点。

课余时间不充电。下班后基本处于散养状态,工作基本吃老本,或者勉强能对付,工作上基本没什么大起色,不算差但也不算好。之前讲“你只有不停的奔跑,才能停留在原地!”,凸显出时代的变化之块,不是大鱼小鱼,而是快鱼吃慢鱼,特别在一些生活、工作节奏都比较慢的二三线城市。人与人之间的差距并不是在工作八小时内拉开的,起决定作用的而是工作之外,所谓工夫在诗外。技术更新迭代的速度远超任何一个时代,比我们优秀的人还在拼命,我们又有什么理由懒惰呢?

不能主动推动事物前进。 主动做一件事跟被动接受去做事,心情都是不一样的,做事效率更是千差万别。主动的人有更多的成长机会,反之在被动中不断的响应别人的任务,这与处于那个层次高低无关。如果处于高层级却不能主动推进任务前进,相信在这个岗位上也不会呆太久。

技术交流分享会仅仅是听听而已。在一线城市这种机会特别多,如果你愿意,一天可以赶好几场。虽说是别人分享,如果没有好好利用,仅仅参加完就离开的话,效果几乎为零。可以事先熟悉讲师履历、分享的内容,带着自己的疑问听,不懂处记录在册,答疑环节将疑问点抛出,多认识些分享会上的人,加入分享会微信群会后继续讨论等等,都能更好的发挥一次分享会的效能。不要让参加技术分享会流于形式。

无法多场景切换角色刚入门时,醉心于开发还是有可能的,随着年限的增加,个人职责会发生改变,再有整块整块的时间去专心某一事务的机会不多,更多的是碎片化的时间切片,面对不同同事、客户、领导、合作伙伴等等,如果不能快速响应各种变化,只能用疲于奔命应付来形容了,工作的条理性更无从谈起。你需要快速切换角色,融入不同环境,能抽象,也能具化,能全局把握,也能细节深入,这样处理起问题才能得心应手,迅速成长。

容易陷入细节。或者说很纠结细节问题,相对的另一面会导致全局观缺失,偶尔还会钻牛角尖。过于追求细节完美的人,也就是完美主义者,事实时完美在现实生活中不可能存在。陷入细节而不自知轻则项目延期,重则错过市场窗口期。把握一个度很重要,需要以大局为重时,就需要牺牲局部的不完善。

不插手开发任务外的其他事务。临时任务在所难免,特别是创业团队,更是没有明确界线的岗位分工,需要时,直接顶上,目标就是把事情做成。仅关注开发任务那点事,显然不足以为更高的岗位做技能储备,如果力所能及又不占用过多时间的话,建议去锻炼一下。经历都算自己的,成长过,谁也拿不走。

不注重关键节点的记录留存。人员流动、业务变更对软件后续的维护都是挑战,仅靠脑袋记,显然不现实。很多朋友说,代码里都有啊,看代码就行了。如果必须拿代码才能说事的话,只能说你太不成熟,设计文档、流程图、数据表格这些辅助理解的东西简直难道是摆设?特别是一些复杂的业务流程设计、复杂算法设计、疑难BUG解决方案等等。虽然敏捷开发不主张凡事以文档必备为准,但必要的文档留存很重要,形式可以不限。


发表评论

电子邮件地址不会被公开。 必填项已用*标注