当了两年软件工程师，我学到了三条生存法则

编者按：从高校校园进入职场，环境的转换通常也意味着生存规则的改变。我们在学校里所信奉和追求的那些在职场环境中是否适用？工作之后，是否只要足够努力、闷头工作就能像在学校一样拿到最好的成绩？本文作者 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 并没有就自己对团队的贡献而四处宣扬，也没有拿自己作为工程师的专业水平去压别人。他似乎并不介意自己在配对合作过程中有多久的时间是自己掌控键盘，占据主导地位。可以说他是我合作过的最优秀的一位工程师。

我学到的第二课：你影响他人的能力取决于你能否帮助他人、引导他人靠他们自己来推导出与你所做的相同的结论。

Bob 几乎从不说“我们就应该这样做，因为……”，他会就你们目前所考虑的一些想法提出几个问题，到你们讨论的最后，你会发现绝大多数情况下，他的问题都会引导其他人与他达成共识。Bob 并不是自己提出什么完美无暇的想法，通常情况下，他都是先提出几个问题，然后得到其他人的回答，其中一个问题的答案通常会实现这样的效果，就是让他说出“这是一个好点子，我们继续探究一下”类似这样的话。但是，就是这样的方式让他对我们的软件质量产生了最积极的影响，因为他拥有着影响我们团队成员推理过程和方向的强大能力。但是，他实现这一目的并不是通过直接分享他自己的想法，更多的是通过提问的方式来实现。

我学到的第三课：在开始考虑一个问题的解决方案之前，先提出许多的问题，这是一位优秀的问题解决者的标志。

作为软件工程师，我们的核心工作就是解决问题。学习新东西是一个需要解决的问题，编码是一个需要解决的问题，沟通也是一个需要解决的问题。优秀的软件工程师就是优秀的问题解决者，而要解决问题的一个好办法就是通过提出问题来理解问题。提出问题表明你尊重他人的想法，提出问题可以帮助你更好的理解事物，提出问题能够让你有更大的可能性得出获得他人认知的答案。最能提出解决方案的人往往就是那些愿意花时间去理解问题的那些人。

关于 Bob 的故事还有一点，他在技术方面很有天赋，完全可以成为团队主力和领军人物。如果他愿意，我相信他都可以成为一名设计师，只是他没有那个想法。Bob 喜欢写代码，他喜欢做域名分析，喜欢设计业务对象，喜欢编写测试套件，喜欢交付高质量的软件。

回顾

回首我做软件工程师的前两年可以说是一趟充满冒险的旅程。我不停地构建软件、破坏软件以及修复软件。我参加了好多无聊的会议，无聊到你真的可以趴在桌上睡着的那种程度。我闷头扎入工作的海洋，体会着其中的酸甜苦辣。

回看最开始的那两年的软件工程师时光，我发现自己有以下几点需要改进：

• 我将工作放在了人之上。我们工作（产品）的问题总是能够自己解决，但是与团队其他成员的关系要维护和修复起来显然难度指数高很多。

• 我将更多地时间用来环顾四周，而不是向上看，向内看。只是一味地看别人在哪些方面可以做的更好，挑别人的问题，并不能让自己成为更好的队友。只有认识到自己的弱点和优势，你才有机会变得更好。

• 在应该聆听的时候选择了说话。只是一味滔滔不绝的讲话并不会让自己变得更聪明，也不会唤起他人的共鸣。

• 在我遇到挫折感觉沮丧的时候并没有与队友和领导开诚布公的交流和沟通。如果他人根本就不知道你的问题所在，那他们自然也帮不上你。

如果你非常看重你的工作并且非常努力，那你可能会成为他人的绊脚石，可能会冒犯到他人，也可能会时常遭遇失败的挫折。无论怎样，请一定记住将人放在第一位，而不是工作。要勇于承担责任，诚恳的道歉，不断进取。能否做到这些决定着你是只能做一名普通的软件工程师，还是成为行业的领导者。

在我接下来沿着职业生涯不断前进的道路上，以下几点需要我时刻谨记：

• 目标：成为最优秀的软件工程师，不积跬步无以至千里。

• 目标：成为最好的队友。如果我不能积极地处理好团队关系，那成为优秀的软件工程师这事就无从谈起。团队凝聚力第一，个人才能其次。

• 目标：分清主次。虽然软件对我来说很重要，但我的信仰、我的婚姻、我的友情以及我的身体健康比软件还要重要。想清楚对你来说最重要的是什么，这一点很重要。我不会为了让自己工作更高效而牺牲这其中任何一样。

原文链接： https://blog.usejournal.com/what-i-learned-in-my-first-two-years-as-a-software-engineer-4e374fdcf0fd

编译组出品。