当陈述需求时间 > 写代码时间,我该怎么办?

前几天在一个群聊里,有几个小伙伴讨论了一个话题:

一个活应该是同事干

但是我与他沟通，把需求明确清晰地传达给他，花费的时间 > 我写这个代码的时间

那么我应该如何做？(当需求实现很简单，但是清晰传达需要说明很多的时候就会这样)

相信这种场景大家也都遇见过,有时候大家想,和你说这么啰里啰嗦,业务也不难,我自己就做了吧.之前我也是这样,一帮总是帮到底,大家讨论后,现在想想,这样不好~

如果这个同事是你的小帮手,但是水平比你差一些,那我觉得这种人还是应该多帮帮,甚至在完成这个任务后,还可以多花一些时间来多提醒指点他,让他成长,日后还可以成长为你的小帮手,日后还可以帮你减轻负担,更轻松~

但是有一种,大家所遇见的,也是所讨厌的,遇到年纪大的养老型程序猿，年纪比我大，级别比我高，但是实际上业务能力从现在看已经不OK了,这类人一般来说比较难沟通,但是不要勿以善小而不为.

先陈述下事实和观点:

年纪大-这是事实,人都会这样,无法改变

养老型-这是事实,但是没被辞退说明不影响工作,也可以

程序猿-这是事实,应具备基本的专业素养

级别比我高-这是事实,但是将来可能改变

代码业务能力差-这是观点,需要举证,但是不排除是我们自身能力的问题

事实既然无法改变,说说观点:

作为程序员,最重要的还是以代码来服人,做技术的一般比较好沟通,不就是你行你上,我不行我不上.代码质量的好坏,靠谱的方法是制定代码规范,提交的代码也应当进行Review,不行不要,相信大多数的公司都有这样的体制.

但是如果代码的质量的确影响了团队工作,需要由老板来解决,沟通.

如果是态度不诚恳,老是心不在焉,那就诫勉他提高责任心,好好写代码

如果是能力问题,水平提高的还是尽快提高,到期了不提高还这样转岗走人.

上边这些其实都是老板的管理问题,不了解员工能力其实是老板的失职,留着影响团队也都是老板的失职.

话说回来,我们作为员工,从自己的角度看:

既然是自己的同事,水平和自己也不上不下,这个活也应该他做,那就应该和他沟通清楚,哪怕多话一点时间,因为一个项目需求总是变,以至于后续的bug维护,沟通清楚后续的他应该自己搞定.老话说得好:陈力就列,不能者止。德不配位，必有灾殃。

还有关于代码,我遇到很多程序员总说别人的代码,这人写的代码垃圾,就跟shit一样,相信大家也都遇见过.这样的人很多,而我自己就是常常被别人说代码shit的那种人(当然,我是真垃圾),但是有一些程序员其实自己本身处于能力上升期,有一些东西不见得就了解,最近我发现高手写的代码难懂的,这样难懂就很容易被不知道的骂shit,但是高手写的难懂是有理由的,就是在他的认知里他觉得很好理解，,但其实他的代码需要较多背景知识才能理解,但是在高手的认知里那些背景知识是基础知识.这样的认知差异,往往会造成信息差,交流混乱.

并且同一个任务，每个程序猿思路都不完全相同，所以代码想分享的话，感觉更重要的是文档，同样的阅读自己一年前的代码可能随着经验的积累很难记得自己当时怎么想的，而文档就简单直白多了.与其争论代码好不好,倒不如好好写文档.

并且在工作的时候，我最喜欢和这样的同事打交道,一个模型算法了解的多，论文看的多；一个运维方面了解的多，有啥服务器的事都能解决；还有一个公司内部超级吃的开，要做什么事，都能帮你找到配合的人(当然,可遇不可求,也感谢帮助我的同事们).就像人对镜子一样，哪怕自己再不好看，对着镜子时候也会觉得挺好的,能力强而谦虚的人一般在一个团队里会很受欢迎，一个团队什么样的人都需要啊，能力强，能抗事的人需要，能力一般，耐苦耐劳的也需要，总要有些脏活累活，需要人干，脾气火爆的也需要，有时候和产品，测试，运维兑，这种人就起到作用。所以一个团队，啥人都需要，并不是说大家都牛掰，就是好团队,和和睦睦,一团火的团队才是好团队.

想想我自己,我本身自己的代码写的一般,在代码的稳定性，代码的安全性上应该都比较差,一直也在学习别人的代码，也一直想努力的把自己的代码写好，但是怎么算足够好，怎么衡量,真的是不知道,很多职位比我高的领导，感觉他们写的代码也是很傻，但是他们对业务，对架构那些东西的理解确实是让我很佩服的。各人都有所长,在一起是缘分.