最近同一部门另一个项目组的一位程序员被”主动离职”了，虽然我未曾与这个程序员共事过，但是听过一两次他的内部分享，感觉技术还是挺厉害的。
后来与一个消息灵通的同事聊天，才知道真正的原因是老大觉得 A 难以沟通，搞得其他程序、QA 都怨声载道。
工作这些年，身边的好多同事来了又走了，主动或被动，这不禁让我思考什么样的程序员算得上合格的程序员。
虽然大家都自称”码农”、”IT 民工”，但我相信，这仅仅是自嘲或者自黑，大多数程序员应该还是认可自己这个职业的。
当然，我算不上一个优秀的程序员，因为我都不曾在开源社区贡献过代码、也不精通白板算法、对技术也不狂热、不 geek。
我的目标是做一个合格的程序员：把本职工作做好，对得起自己的薪水，平衡生活与工作，996 什么的我是难以接受的。
对于程序员而言，技术过关当然是非常重要的，这是硬实力。然而只会技术也是不行的，毕竟大多数的程序员还是要与人打交道，软实力也是不可或缺的。怎样才能算合格，我认为有以下几点：
3
写代码的时候先想清楚了再下笔，而不是先写出一堆代码，然后在开始修 Bug。
修改 Bug 的时候，多看看上下文，搞明白为什么出 Bug，修改这个 Bug 可能带来的影响，然后再修改。
反面教材有两种：
- 随便改改就把代码改好了，但自己心里并不清楚为什么这样修改就修好了，撞运气，也许还有其他同样的 Bug 也发现不了。
- 头痛医头脚痛医脚，不仔细评估修改的影响，这样往往会引入新的问题。
程序员成长的一个办法就是修 Bug，修别人用不了的 Bug，但前提是搞清楚 Bug 的缘由，这样才能避免类似的错误，有所收获。
顺畅沟通不是巧如舌簧、也不是忽悠达人，需要的只是耐心倾听，然后清晰表达自己的意见。
现在的软件开发，已经不再是单打独斗的年代，大多数的软件、产品都需要多人、多部门的协作。而交流、沟通是非常耗时耗力的。
沟通之前，先想好目标，组织好语言，尽量不要发散、不要跑题，对事不对人。对于重要的事情，保留沟通记录，最好有邮件，免得说不清。
沟通是门复杂的艺术，最基本是听明白、说清楚。
作为一个程序员，要被 PM 怼、要被交互怼、要被 QA 怼，再变态的需求都可能有，QA 给你提的 Bug 可能也不属于你。而且，还有猪一样的队友（自己在别人眼里何尝不是这样呢）和下属。
不管谁是谁非，发脾气、吵架都一点用没有，吵完还是得解决问题。calm down，有怒火也得等个几秒再发作，也许这几秒理智思考一下，就能解决问题。
能力（技术能力）与责任心谁更重要呢，都重要。如果一个新人有培养的潜力，那么责任心就更重要。
两个人，第一个技术能力很强，但责任心很差，对项目的事情也不上心；第二个能力差些，但责任心强，是自己的问题一定负责到底，即使自己不能解决也能主动寻求帮助。
我觉得前者对项目的危害更大，特别是项目紧要时期，因为能力强的人一般负责的是比较复杂、困难的功能，别人上手也需要时间，这个时候如果摞担子，Bug 也不修，那么就很为难了。
不负责任的典型表现就是扯皮、甩锅：这不是我的 Bug、不关我的事。
有协作的地方更容易出现问题，比如前端与后端、各个部门之间。如果不清楚到底是谁的问题，不妨主动一点，帮助排查。
作为程序员，总有一些工作是以前没有做过的，也许来自产品人员的需求，也许来自项目自发的优化。
我见过一些程序员，在面临未知的问题、挑战时，总是习惯于说：不会、没办法、不可能，这样的程序员就算不上合格的程序员。
事实上，这样的程序员是给自己过早地留好退路，事实上问题可能并没有想象的那么困难，也许经过一番探索就能解决。
如果习惯于对未知说不，那么在别人看来就是能力不行，影响个人形象与声誉，而且总是待在自己的舒适区也不利于自我成长。
当然，也不是说要盲目自信，急于拍胸脯保证一定能解决，这样往往是坑自己。
所以，面对新的需求，谨慎对待，既不轻易否决也不随意承诺，而是再理清需求先去研究一下，评估是否能完成，需要的资源与时间。
本帖转自：51cto技术栈公众号
发表回复