转载

写给即将离开校园成为一名程序员的几句忠告

　　文/朱英达

　　转眼间又到了一年一度的毕业季，如今回首自己真正意义上的大学生活已过去整整两个春秋。谨以此文献给那些即将毕业的和还未毕业的学弟学妹们。

　　这篇博客的标题定的很大，说实话我不知道自己有没有资格在这里对如此之多的”互联网行业未来从业者”的职场起点说三道四。

　　虽然我无法像众多前辈一样在博客中站在一个从业多年的技术经理或技术专家的角度来谈程序员的职业规划，但对于”程序员职场的起点”这个话题，你将要面对的一切都是我不久前所经历的，并且我深知此刻初入职场的你需要这些建议!

　　初入职场，对一个程序员来说最重要的是什么?

　　2014 年时，在 58 同城的校园宣讲会上，休息时我曾单独找到当时来到现场的唯一一位程序员讲师”沈剑”，询问了他眼中的初级程序员应有的职业规划，他的回答令我醍醐灌顶，至今记忆犹新:

技术基础
业务积累
职场情商

　　技术基础是指作为一名程序员来讲的一些基本的、通用的技术，诸如数据结构、算法、数学能力、软件工程理论、操作系统基本知识、编译原理以及你所从事的技术岗位所使用的技术。这些是学校里教给你的东西，无论学得怎么样，在你的程序员生涯中它们都将跟随你一辈子，因为无论你从事什么技术岗位，在这个行业中，这些东西都是共通和必要的，是身为一名软件工程师的立足之本。

　　业务积累指的是你在部门里边具体承担的业务，相对前一条来说，这一条是不存在行业中的普遍性和通用性的，然而如果说前面一条是使你顺利拿到校招 offer 的前提，那么这一条则是你所在的公司每个月付给你”比任何一个行业的任何职位在初期都要高得多”的薪资的理由。换言之，如果你是一名实习生而你手上却没有任何业务积累，你该为自己能否得到 offer 而感到忐忑，而相反的情况如果你手上已有很多业务，每天忙得要命，你也该清楚现在的这个部门给你发 offer 应该是板上钉钉的事了。

　　第三点也许是最容易被我们程序员这样一个群体所忽略的——情商。这也是本文真正想要表达的重点，是我想在这篇文章中给你的建议。

　　程序员的情商有那么重要吗?

　　引用大家所熟知的 OOP 的思想，无论你是一名服务端、Android 还是机器学习算法、数据挖掘工程师，你的职位 title 都是从软件工程师这个父类继承下来的，而软件工程师这个职位继承于工程师，更继承于”公司职员”。

　　但凡是一名公司职员，就免不了职场中的人情冷暖、酸甜苦辣。因为身处公司最基层，每一个工作日你无法避免的要与各种人和事打交道。说的直白一点，有人的地方就有利益，职场中人与人之间的利益不可能没有冲突。

　　当你的个人利益与其他同事的个人利益、团队利益甚至公司的利益发生矛盾时，你至少应该清楚没有哪个职场人能够避免这一点。

　　在诸多利益交织下，到一定程度以后你会明白始终维持着这一切的不是别的，是人情!

　　那些充满”正能量”的新员工培训可能告诉你什么”主人翁意识”什么”不想当老板的员工不是好员工”，然而在现阶段对你来说最重要的却是融入团队，和你身边的同事还有领导搞好关系。

　　如果你跟部门里的任何一位同事关系闹僵，我敢保证在这个公司里你将举步维艰，每天上班的心情犹如上坟。

　　情商体现在哪里?

　　对于一名初入行业的软件工程师来说，你不只需要和代码打交道，更需要与产品沟通需求、向领导汇报工作进度以及跟其他技术岗位的同事协商和联调代码。

　　我从没见过或是听过哪个公司的哪个项目可以从产品策划到 UI 设计再到前后端编程开发调试测试上线发布后续运营维护等工作全部由一个人来完成的，如果有，这也一定不常见。

　　我知道校招生们多数愿意进 BAT 这些大公司，我当年也不例外，并且回头看来这一步也确实没有错，大公司给你的不只是更高的起薪以及毕业时在老师们面前优人一等的光环，更重要的是你将会认识更多和你一样优秀的同龄人，你的视野将会更开阔。

　　然而细细想想在一个大公司里，我们工作的更多时间是开会而不是写代码。扪心自问在一个公司里干了一个月以后，你究竟写了多少行代码?你又开了多少个会?

　　这不叫效率低下，在公司体制庞大以后这些沟通我认为全都是必要的，这些花在管理和沟通上面的成本对公司来讲绝对值得，就像一块硬盘能存下多少数据就必须产生相应的区块保存数据的物理地址和逻辑地址，再加上系统级的内存管理、应用级的框架消耗和垃圾回收，仔细想想我们每天使用的手机、平板和电脑设备的更多内存资源和 CPU 使用其实都是消耗在了设备自身对数据的管理上，机器尚且如此，更何况人呢。

　　所以不要对开会产生反感，每一次会议都是你学习的机会，更是你表现自己的机会。如果在一次会议上你提出了一处 UI 设计稿上面的缺失刚好是你的 leader 没考虑到的，他下次还会带上你一起开会; 如果在服务端 Rest 接口确认的过程中你想到了一个 leader 们没考虑到的数据项，这很可能为整个开发周期节省一到两天; 与产品沟通需求时，并不是一味地否定和砍减需求，也不是毫不过脑子的点头，你应该设身处地的站在把一个产品做到尽善尽美的角度去跟对方沟通，删掉对大家都没有利益的需求，必要的时候甚至增添一个对双方都有收益的需求。

　　这一切都能够让你的工作状态更为积极，而积极的工作状态对你对公司对所有人都是有利的。

　　初期应该如何融入团队?

　　幸运的是程序员毕竟男多女少，因为我想举的例子和足球有关。我很爱看球，我们往往关注的都是那些场上闪耀的球星，然而任何一个年轻的小球员在初入球队时都是从替补席冷板凳坐起的，哪怕你是罗纳尔多这样的超级巨星(球迷们不要怪我，只是我觉得拿大罗来举例相对争议小一些)。

　　初入职场的你，就如同一个刚进入球队坐在替补席上的小球员一样，最初很可能连 90 分钟末补时的那几分钟上场机会对你来说都是无比珍贵。

　　在这种情况下，要学会捡别人不要的活儿干，而不是坐在工位上打开 qq 和同学抱怨自己在部门里不受重视。

　　举个例子：如果说部门里缺前端，你作为服务端也该自己学会写后台管理页面，这些东西 leader 看在眼里，他会明白你的努力。

　　另外千万不要放过任何和同事们沟通的机会，哪怕是午餐时的闲谈。这恰恰是发现一些”可捡的活儿”的一个途径。

　　遇到技术上的问题该怎么解决?

　　对于这个问题的看法有很多版本，我个人偏向于尽量靠自己解决问题。

　　原因有二:第一个原因是作为一名初入岗位的工程师，不是看不起你，很多时候你对自己遇到的问题究竟该不该问别人，该问的话该问谁你都是不知道的。在这样的情况下，你很可能把一个 google 五分钟就能解决的程序语法报错拿过去问了你的同事，问问题存在沟通成本和理解成本，你的描述不清以及对方缺乏上下文了解这些都可能增加以上两个成本，这样一来不仅耽误双方的时间，长此以往还会让对方觉得你记得技术基本功不扎实，独立处理问题能力差。第二个原因是，即使这个问题真的是一个较为冷门的编程语言运行环境层面的 bug, 你在不经过任何思考的前提下把它抛给了你的导师或是你的 leader,他很可能是遇到过这个问题的，于是直接把问题的答案告诉了你，这样你就完美地错过了一次在你所使用的语言环境下亲自踩坑然后填坑的机会。

　　我认为对于程序员来说，总有一天你要独立面对这些编译环境、运行环境的偏门 bug,因为你不可能一辈子只写一门语言或是只从事一种开发岗位，你现在可以问你的导师问你的 leader, 那么你自己当上 leader 之后又该问谁呢?总不能告诉自己的老板，这问题太难了，我解决不了。

　　我记不清好像是之前百度的首席工程师说过的一句话:衡量一个程序员价值的标准并不是他掌握了多少知识，而是他掌握的知识与学会这些所花的时间之比。

　　对于初入开发岗位的你来说，每一次踩到一个坑然后独立填坑的经历都将会加速你对更多技术领域内的知识和问题的学习速度，也将会提高你作为一个工程师的价值。

　　如何与产品沟通?

　　在技术圈里这是老生常谈的话题，我认为与产品沟通的过程中是最能体现出一个程序员情商的时候。无论对方提出的需求是怎样的，你考虑问题的逻辑应该是:当前提的这一条需求做完以后对产品有什么收益?对技术这边又有什么收益?更重要的是 leader 们是否会在乎这一点?

　　然而这一切都应该发生在你的内心中，权衡利弊之后如果有什么没考虑到的你可以提出来，如果并不是十分确认自己的想法，你可以等会后私下里和你的 leader 提出自己的看法，这既是对 leader 的尊重也是节省开会时间。

　　幸运的是，在互联网这个行业里，需求沟通的过程中，技术人员的话语权通常还是较大的，然而绝不要滥用你的话语权。

　　我可以扪心自问的说，在我正式入职以后沟通过的每一位产品，没有和任何一位发生过争吵，相反的是产品们都愿意与我对需求。

　　这并不是因为我把 PM 们当大爷一样供着，对任何奇葩的需求都有求必应，而是因为我往往把”与 PM 对需求”这件事放在”人情”这样感性的层面来考虑，而不像很多程序员那样只考虑代码逻辑的理性思维方式。

　　人是复杂的动物，一个 PM 提出了一个看似无理的需求，你却不应该不问青红皂白直接拒之门外，设身处地将心比心的想一想，公司里这样复杂的环境下，他/她是否也有自己的无奈和苦衷?如果有，这个问题是否存在其他折中的解决方案?

　　武断砍需求的程序员往往错过了这样的商讨”折中方案”的机会，同时也错过了一个让 PM 认可你的机会!这一点其实很重要。

　　我见过很多同期进公司的校招生，他们把职场中”老油条们”习以为常的做事方式直接照搬到了自己的行事风格当中，内心里对 PM 的抱怨将会在潜意识里左右你与 PM 沟通的态度和方式。

　　换个角度考虑，我倒觉得在其他职位的人眼中，你的技术多么多么的 NB 他们是无法直观洞悉的，每一个无理取闹的需求也都是一个你证明自己的机会。

　　更重要的是，公司里与产品交涉问题并不同于市场上买菜那样，你们的工作很可能在接下来的几个月中都存在沟通和交集，今天你卖给他一个人情，明天他也会替你扛一个线上的错误， (说实话程序员在代码上线之前往往喜欢叫 PM 来做最后确认，言外之意是上线是你确认的，出了问题也得你扛着。我觉得一个项目是大家一起做的，说句良心话，把所有的责任一股脑全部都推给 PM 我个人认为也是不公平的,PM 往往在很多项目中充当着”背锅侠”，人要相互理解)人非圣贤孰能无过，任何线上的代码都不可能永远是不出错的。PM 对于一个之前敲定好的需求的修改，确实有可能是出于他本人工作上的疏忽，但是这不代表你的工作就不会出错，如果人之间没有”良好的信任关系”，问题就会被相互放大，像手电筒一样给别人挑错很简单，难的是互相的弥补对方的失误从而建立一种长久的友好合作关系，而能做到这一点也正是所谓情商的体现。

　　情商不是叫你如何精明的算计对方，那叫”别有用心的智商”，情商是包容与理解。有了人情作为基础，我觉得没有哪个 PM 会和你在一两天的 deadline 问题上面扯皮。

　　即使利益之间的冲突真的无法解决，也没有任何折中方案，你至少可以把问题记录下来，拿到 leader 们那里交给他们去做决定，而没必要当面撕破脸伤及双方的感情，毕竟产品是公司的，人际关系是自己的。

　　如何看待加班?

　　加班就像借钱，原则上必然是救急不救穷。然而并不是说对于一个”穷”的部门程序员就一定要选择离开，这既不是负责任的表现，又错过了一个成为部门核心骨干力量的机会。很多公司里的 leader 都是在危难关头扛下了部门的人手不足的压力,leader 的职位也就顺理成章。除非部门真的气数已尽。

　　ruby on rails 的作者曾说过，熬夜加班相当于借高利贷，偶尔一次可能是难免的，但如果你的工作长期需要你熬夜加班(IT 运维岗除外)，你可能确实该考虑换一份工作。

　　最后祝愿各位未来的程序员在校招的潮流中能够成为 offer 收割机，并且得到自己真正心仪公司的 offer!

　　如果觉得本文中说的确有些干货，欢迎各位同学点击文章底部的打赏按钮为我的博客募捐。捐款不在多少，却是一个能够让我坚持精品原创博客的动力。对 web 方面感兴趣的同学，可以关注下我最近在搞的一个开源项目 veneno, 项目主张以 Node。js 来进行 web 安全方面自动化攻击、防御的一些实践。

正文到此结束