头图

作者:东东拿铁

前言

当我们谈论程序员的工作习惯时,常常想到的是高效的编码技巧、精密的逻辑思维以及对新技术的敏锐洞察。

本文不聊技术,想谈谈在日常工作中,程序员可能会有的四个坏习惯,如果你认识不到,可能会影响你的工作效率、影响团队协作,甚至影响你的职业发展。

下面就让我们看看这些坏习惯都有哪些,你有没有中招呢?

如有雷同,纯属巧合

低头干活,不看方向

对于方向的迷茫
每天睡眼惺忪的上班,打开开发工具,CRUD开始了。喷喷老板,吐槽吐槽产品经理。

开发前
这需求是啥啊,就一句话?
有产品吗,没产品没法做?
这prd写的不清晰啊,好多东西没写清楚,没法做

开发中
延期了?没事,需求拆解的就不到位。
这个功能什么时候上线?who care,测试完了,你们上线就行

上线后
现场出问题了,异常case你prd也没要求,报错了不能怪我?
这个功能给谁做的?who care,我的需求完成就行了
这个功能上线效果怎么样?who care,我的任务完成了,其他的我不需要关心了

如何避免
不知道你有没有遇到过上面的场景呢?如果有,那么恭喜你,看完我的讲述,你会知道如何改变自己的一个思维误区,那便是学会”以终为始“。

我们常见的思维模式,是线性且顺序的,先有A,再有B,走完B,再走C。为什么会这样呢?

我们人类都是从远古进化而来的,在那个危机四伏的生存条件下,思考并不是一件特别有用的事情,且会耗费多余的能量,所以几十万年的进化,留给了我们一些短视的行为与习惯。

那什么是以终为始呢?很简单,做一件事情之前,想一想做完结果是什么样子的。

如何改进
似乎你也发现了,在做事之前,你要记住一件事情:遇到事情,倒着想。

任何事物都会经过两次创造:一次是在头脑中创造,然后才是付诸实践,进行第二次创造。

比如,互联网环境,北上广深,是非常好的选择,你在二线城市,你会怎么去选? 去北上广、或者留在小城市的抉择。那么你得想清楚,去一线城市,你会更换工作环境,面临互联网较大的压力,甚至没时间恋爱,陪伴家人。但同样的,工资可能会很高,你也能获得更快的成长。

留在家乡,你的工作可能非常清闲,五点半就能下班。但你可能永远没法参与到一个几千万用户都在使用的APP中去,你的技术能力和眼界,会受到环境制约。

工作中,领导安排的任务,是为了解决什么问题,问题的背景是什么?谁是你的用户,谁是你的客户,功能做出来,真的能解决一开始面临的问题吗?工作是否能量化,如何更快的拿到用户反馈,来持续迭代与改进。这些你也要去考虑,而不是简单的编码、测试、发布。

不做任务分解

是什么
事情想清楚,下一步就是动手去做了,面对任务
老板问你排期几天,你说评估不了,做一步看一步
或许你技术能力很强,听到需求内心里大致就有了技术方案,然后就,直接上手敲码了。。
不区分核心功能,事情不区分轻重缓急,想到什么做什么
代码方法都不拆分,金箍棒代码满天飞,更不用提单元测试

为什么
有一个关于程序员的经典段子:这个工作已经做完了80%,剩下的20%还要用和前面的一样时间。
为什么会出现这种问题,很重要的一个原因就在于没有很好的拆解任务,所以并不知道要做的事情有多少。
面对一个大问题,我们都很难给出答案,主要有以下三个原因:

  1. 复杂性和不确定性,一个大问题通常有很多复杂的结构和多种因素考虑, 我们很难掌握完整的情况去做出判断。
  2. 资源限制,解决大问题通常需要很多资源,比如说新建一个系统,可能需要7个工作日,但是一个小模块,只需要1个工作日就能完成。
  3. 失控感,进度无法把控,就像最开始的例子,完成进度和实际进度,有着较大的偏差,会让我们有极强的失控感。

但回答小问题却是我们擅长的。 通过任务拆解,我们面临的就是一个个清晰可落地的问题,可以更集中地解决每个小问题,逐步地朝着解决整体问题的方向前进。

怎么做
如何去做的关键,是怎么给出一个可执行的分解。

重点来了,拆分的,一定要可执行。每个人对于可执行的区分,是有很大不同的。不同的地方在于可执行的定义,你是否能清楚地知道这个问题该如何解决。

举一个例子,比如要做一个登陆页面,而我是做后端的。那么我的任务可能会这么拆分

  1. 后端:提供验证密码接口
  2. 前端:前端技术选型,学习前端语法(目前我啥也不懂)
  3. 前端:写html页面
  4. 前端:完善前端样式
  5. 可以看到我对前端部分拆分较细,因为我不了解,所以我把它拆分成了我能想到并且可执行的多条任务。后端部分虽然可能需要建表、确认密码加密,提供接口,但对我而言,一个任务拆分就可以了。

所以,面对复杂任务,拆解成你可以直观评估并且可执行的子任务,更好的完成任务拆分。

不沟通,不聆听

是什么
产品的需求评审完了,没听懂也不问,做不下去了再说
合作同事进度怎么样?不知道,测试进度我不管
上线后效果如何,用户反馈怎么样,那更不需要关心。

为什么
有一些新晋程序员,并不是特别爱沟通,其实这可能也与我们从事的工作有关系。
专注于技术:程序员对技术本身非常感兴趣,他们更愿意花时间学习和掌握新的编程技能,而不是花时间与他人交流。
时间压力:在工作中,我们通常面临着时间限制,我们既要技术方案设计,还要完成编码工作和配合测试。在这种情况下,他们可能会感到沟通会消耗过多的时间,因此更倾向于专注于编程任务本身。

很多程序员只希望安安静静地写好代码,但事实上,对于大多数人来说,安安静静是不太可能写好代码的,只有不断扩大自己的工作范围,才有可能把工作做好,那么我们要怎么做呢?

怎么做
作为员工,我们需要向上沟通,了解领导的目标、预期,确保工作进度,规避风险,做出成绩。
作为领导或者组长,你不但要做好向上沟通,与团队的沟通更为重要,为大家制定目标,确定方向,甚至是关注每个成员的状态与后续的成长。
做为普通开发人员,我们要关注使用情况,及时拿到线上反馈,完成迭代。因为我们通常会欠缺用户视角,在与产品经理的交流中,你是不可能有机会的,因为他很容易用一句话就把你打败:“这就是用户需求。”

(顺手推几个技术大厂的机会,前、后端or测试,感兴趣就试试

用人工,不用工具、自动化

如何用好工具和自动化?
程序员的日常工作,是打造工具、系统,来解决别人的问题。但是你有想过,你自己的工作,有合适的工具来帮助你自动化,减轻你的压力吗。

在上家公司,我遇到的一个案例,第一次让我认识到,程序员的自动化,有多么的重要。

推荐团队负责的系统,涉及到多个推荐模型、数十个数据源,甚至是线上的多个配置,在信息流中刷出来的内容,对用户是黑盒的,因为你最终看到的5个内容,可能是由几万个内容里面根据推荐策略选出来的,看到什么,不看到什么,非常复杂。

但是对于公司内的开发人员,需要排查推荐问题时,即使有ELK,logId,来定位问题也是极为繁琐且耗时的,因为数据量大,不可能所有地方都输出日志,因此排查问题非常麻烦。

后来他们开发了一个内部工具,需要排查内部问题时,只需要把你的用户ID配置上实验参数,推荐出来的几条内容,每一条为什么展示,被抛弃内容的原因和其他关键信息,都能结构化的输出在工具内,无需去看日志,即可排查各类问题,起码提供了很多信息。

反观我自己,产品需要我排查的问题,我可能要去看日志,甚至看代码,或者因为某个关键信息没打印日志而焦急,偶发的一些问题,占据了我非常多的时间。

为什么要用好工具
程序员的工作中,天然就存在着需要重复的工作,我们需要从重复的工作中跳出来。

BUG的排查定位,某一个业务流程出现了阻塞,你是不是需要查询数据库数据,定位上下游有没有问题。

代码重构,业务不断迭代,功能需求也在逐步丰富,原有的设计不满足,频繁进行重构。

测试、调试,构建各种测试数据,编写测试用例,尤其是在复杂的系统中,可能需要重复执行相似的测试和调试过程。

部署与发布,代码修改后,发布上线也是重复的工作,代码是否能自动合并,能否自动发布,是否能够监控发布状态,都是些重复性的任务。

怎么做
使用脚本、工具或自动化流程来简化和自动化重复性任务的执行。

将常见的功能封装成可重用的模块或库,以便在需要时进行调用,减少重复编写代码的情况。

审查和改进工作流程,消除不必要的重复步骤,提高工作效率。

说在最后

好了,文章到这里就要结束了,总结一下,程序员的四个坏习惯

  • 低头干活,不看方向。学会“以终为始”思维模式,先在脑海中构思,再去落地实践。
  • 不做任务拆解。学会拆解成,可执行的子任务,以便更好的管理时间,拆分任务优先级。
  • 不沟通,不聆听。学会向上沟通了解大方向、目标,让自己有着明确的前进方向。向下沟通,保证团队能够拧成一股绳,劲往一处使。
  • 不会用自动化。 学会变“懒”用工具,解决自己工作、生活中重复的工作,让自己轻松起来。

幸福的闹钟
50 声望11 粉丝