当了两年软件工程师,我明白了这三条生存法则

编者按：从高校校园进入职场，环境的转换通常也意味着生存规则的改变。我们在学校里所信奉和追求的那些在职场环境中是否适用？

工作之后，是否只要足够努力、闷头工作就能像在学校一样拿到最好的成绩？本文作者Mitchell Irvin 分享了他进入软件工程工作两年之后的所思所想，其中并不仅仅适用于软件工程师，对于告别校园、初入职场甚至有过多年工作经验的“老手”都有很大的借鉴意义。

接下来你会看到我的一些个人职业经历，包括成为软件工程师以及工作两年之后学到的一些经验、教训和其中存在的一些遗憾之处。

大学和工作场所

2015 年，我还是佛罗里达大学的一名学生。当时，我研修了一门可能是整个学院最难的课程，当时负责授课的教授在课程展开的那个学期内会分配给学生多个团队项目。在每个项目结束时，这名教授会单独对每位学生的表现进行评估。然后在分配下一个团队项目时，他会将之前项目任务中表现最优秀的学生整合到一个组，表现最差的学生会继续留在他们原来的组。这样到学期结束时，班里的学生要么是竭尽全力并且成功进入了一个强大的团队，要么是最终待在了一个表现差劲的团队。这样的分配与激励方式很美妙，强者不必去忍受弱者或者是为弱者买单，而弱者可以选择让自己变得强大，否则就只能面对失败。用“唯才是用”（meritocracy，也有译为优绩制度，指应该根据才能、努力以及成果来评定一个人，而不是根据性别、种族、年龄或财富等其它因素）一词来形容这一环境系统可谓最恰当不过，这样的系统奖励的是那些最有才华的学生，而那些不努力的学生也必须自食其力，自己承担后果和责任，我真的非常喜欢这种环境系统。

一年之后，我毕业了。当时的我干劲十足、精力满满、胸怀大志，十分理想主义地准备在我过去四年学习的专业领域内大干一场。实习结束之后，我收到了来自一家大型企业软件工程师职位的邀请，我接受了这一职位，内心渴望自己能够成为一名优秀的软件工程师。

开始我参与了一个项目，这一项目严重缺乏相关支持资源。我们负责构建一个Web 应用程序，这一应用程序的功能与大多数Web 应用程序的功能无异：公开一些数据并且可以让用户操作这些数据。我和其他两位工程师一起负责开发工作，另有一位质量控制工程师负责测试方面的工作。仅仅几个月的时间我就开始认为自己是这个团队中拱心石般的角色，负责撑起一切。用户需要我们去构建一个新功能吗？没问题，我能搞定。需要有人去促成一下回顾会议？当然可以。很

快我就发现自己所处的是一个没有我的努力就毫无进展的环境体系。就这样，在我22 岁那年，我在一家财富25 强企业扮演起了首席工程师的角色。

但是问题在于，尽管我在近一年的时间里一直承担着团队的绝大部分工作任务，我所得到的报酬仍然只是团队里其他经验丰富成员的一小部分。我没有得到“A”的学分成绩，他们也不是“F”，我没有分到股票期权福利，休假时间也更少了。我不久就意识到了这些，之后很快我的挫败感就明显地表露了出来。当与那些不熟悉该软件的工程师合作时，我很难再对他们保持耐心，很难再展示出乐于助人的态度。我的冷漠感不断增长，工作效率急剧下降。如果我与另外一位工程师合作负责一项工作，那我保持与他的工作步调统一（即便可能只是我原来工作效率的5%），我也仍然算是做了我的工作，对吧？

我就是在这样的状态中度过了这一项目最后三个月的工时间，项目完成的并不算从容，团队士气低落，没有人为过去这14 个月的“努力”终于开花结果而兴奋。更重要的是，我知道其中一些队友不会再为将来可能与我合作而心存期待。我这才开始意识到我对于工作环境的态度已经对我以及周围的队友产生了不利影响。

几个星期之后，我发起了一项调查，关于该如何让自己成为一名更好的队友这一问题而寻求其他队友的反馈。最终的调查结果有一点非常明确，那就是个人表现并不能决定一切。在我开始职业生涯之后，我想当然地认为工作场所也是采用“唯才是用”的分配和选拔标准，就像我在大学校园里的那门课程一样，强者会得到应有的奖励而弱者也会为他们自己的行为买单。正是这种看法影响到了我与他人合作的能力，使我不再感谢他人的贡献和付出，丧失了谦虚学习和耐心指导他人的品质，团队其他成员对我的印象也成为了“过于看重个人表现”。

我学到的第一课：你的技术实力（硬技能）很重要，但是你与同事的关系（人际关系/领导技能）与之同等重要。

要想成为一名出色的软件工程师，你需要用多年的时间不断磨练自己的专业技能。随着时间的推移，你会进步、会遇到瓶颈、会上下沉浮，或许也会遭遇邓宁-克鲁格效应（Dunning-Kruger effect，能力欠缺者们沉浸在自我营造的虚幻的优势之中，常常高估自己的能力水平，却无法客观评价他人的能力）所描述的情节。在这过程中，你会犯错误，会吸取他人的经验教训，也会分享自己的所学所思。毫无疑问，你必须要具备强大的专业技术能力，但是如果这就是你唯一的专长，那你很快就会发现自己处于一个很不利的境地。如果你的目标是成为一名最优秀的软件工程师，那在通往这一目标的旅程上你必须也要让自己成为最优秀的队友（也可能是领导者），而这首先就意味着你要看重他人的付出。

我合作过的最优秀的工程师

九月的一个上午，两名新签约的员工加入了我们团队。因为我们团队一直以来都以二人配对合作编程为安排准则，于是当天我就和其中一位新加入的队员一起开启了配对编程工作。在接下来的七、八个小时里，这名工程师，我们暂且称呼他为Bob，不停地问我各种问题。在我们开发一个新功能时，Bob 问了一些关于我们所用的语言和框架方面的问题。在我们打磨具体的业务规则细节时，Bob 又问了我关于产品以及我们正在解决的问题方面的信息。那一天，Bob 并没有写多少代码。说实话，到下班时，我对Bob 的表现有些失望。我本来对于他作为工程师的专业技能有着很高的期望，也满心欢喜地以为自己可以从他身上学到不少东西。

第二天，Bob 和我一起负责编写另一个产品功能。我写出了该功能的初始测试用例，并进行试运行，当屏幕上所有的检查标记都显示准确无误之后，我不禁露出了微笑。Bob 在一旁看着，面露沉思之意。在我的测试结束之后，他使用这一测试方法，并且改变了其中一两行的代码。我开始表示反对，“等等！你这样做不对。”他点点头表示同意，然后继续运行我们的测试用例。这样所有测试都以通过告终，令人惊喜！

几周过后，Bob 和我依然在这样配对合作。在我们工作过程中，他依然会不断地提出问题。在我主导工作时，他会提出一些建议，在他认为合适的时候，他也会介入短暂地占据主导地位。我问了他几个关于我们所用框架和语言内部工作模式的问题，除此之外，他还向我介绍了一款我并不熟悉的OO 设计模型。他对域名和业务问题提出的一些疑问让我发现了软件中的漏洞所在，他找出了我们代码中所存在的错误和缺陷，而这些本来是我根本发现不了的问题。但现在，我也发现了这些漏洞，清晰无比的存在。日子一天天过去，Bob 和我解决了他发现的这些漏洞，对软件设计进行了加固和防护，大大改善了业务问题和我们所写的代码之间的关系。

在我们团队合作的整个交流过程之中，当Bob 认为其他人犯错时，他并没有强行去让他人接受自己的观点，也没有偏执地想要去在与他人的辩论中占据上风。但是他不停地提出问题，在别人回答这些问题的过程中，他们经常会发现自己也存在Bob 提出的这些疑问。在于软件相关的几乎所有的决策过程中，我们几乎都会发现Bob 所提出的问题的踪影。Bob 并没有就自己对团队的贡献而四处宣扬，也没有拿自己作为工程师的专业水平去压别人。他似乎并不介意自己在配对合作过程中有多久的时间是自己掌控键盘，占据主导地位。可以说他是我合作过的最优秀的一位工程师。