其他分享
首页 > 其他分享> > 梦断代码读后感(三)

梦断代码读后感(三)

作者:互联网

发布日期:2021.4.09

误区1: 加强沟通就是多和人说话。

这一点最大的问题,就在于狭义了的理解了沟通的意义。对于技术人来说,沟通的方式是多样化的,比如说,书写技术方案文档,每日工作邮件,添加代码注释,提交代码的时候是否有完整的git comments等等。而且,以上这几点对技术人而言,比直接说话沟通更重要,因为如果已经有技术文档,就不用每次来一个新人,就需要重新语言沟通一遍,提升时间效率;如果有代码注释,其他程序员就可以快速的知道API中的输入输出和参数的含义,做到快速接入,而不需要找到原作者交流一遍。

对于技术人而言,真正的沟通其实早已经融入到他自身的工作中去了。

沟通是桥梁, 但沟通并不单纯是自下而上的。在技术团队内部,沟通很多时候,是和团队里的其他"技术"进行的。需要通过合适的方法,将信息在技术团队中同步开来。这也是为什么,越来越多的技术团队开始引入JIRA,Confluence, Code Review Board等各种工具,帮助大家做好沟通。

误区2: 沟通是为了取悦别人

这个问题还是比较常见的,实际工作中,一些技术的同学,在需求评审过程中,对于业务或者产品提出的需求,没有经过认真的准备和思考,就一味的答应,认为这就能得到产品或者业务对自己的认可,以为这就解决了沟通的矛盾和问题。

在我看来,沟通的第一要素,就是输出确定性。这就意味着,准确的回答比满足对方的要求更重要,将偏差暴露在早期,远比最后无法达到,带来的失望好太多,更别说,早期问题可以有时间去找其余的解决方案。对于个人而言,沟通的确定性是个人专业的一种体现。

沟通能力与代码量积累成反比。沟通不好会多写好多冤枉代码,而且还没有得到满意的结果。

误解3:沟通能力=会聊天

技术人的沟通能力绝对 != 会聊天,而是拥有足够的专业能力+会聊天, 技术水平是"沟通能力"的基础。如果没有扎实的技术基本功, 对每个环节都没有深入认知的前提下,即使会聊天, 善于沟通,所传递的信息也可能是错误的,我也见过很多沟通伶俐的工程师,进度汇报非常漂亮。但是,他代码的质量可能糟糕到我不得不考虑重新更换一次人员。

反过来说,如果一个技术人总是能用一个简短的比喻,或者小故事,让完全不懂技术的业务人员知道他在做什么, 能讲明白引入某一项技术的优势和作用。那么他的沟通能力就是很强的。

工作本身分两种,一种是“社会化”的,就是跟人打交道的,比如销售、市场,还有一种是“非社会化”的,做技术开发的明显是属于这一类。那么“社会化”和“非社会化”之间的沟通,说白了,就是学会用别人的语境沟通,这是个很重要的技巧。

程序员尽管不合群,却真的需要与他人倾谈——形式越随意越好。

为了完成工作,程序员得有办法随时询问和得到解答,在团队内部传播答案,并保存答案豫备不时之需。

标签:读后感,沟通,代码,技术,社会化,团队,梦断,聊天
来源: https://www.cnblogs.com/liuyang-cn/p/14908670.html