当了两年软件工程师，我学到了三条生存法则
|
几周过后，Bob 和我依然在这样配对合作。在我们工作过程中，他依然会不断地提出问题。在我主导工作时，他会提出一些建议，在他认为合适的时候，他也会介入短暂地占据主导地位。我问了他几个关于我们所用框架和语言内部工作模式的问题，除此之外，他还向我介绍了一款我并不熟悉的 OO 设计模型。他对域名和业务问题提出的一些疑问让我发现了软件中的漏洞所在，他找出了我们代码中所存在的错误和缺陷，而这些本来是我根本发现不了的问题。但现在，我也发现了这些漏洞，清晰无比的存在。日子一天天过去，Bob 和我解决了他发现的这些漏洞，对软件设计进行了加固和防护，大大改善了业务问题和我们所写的代码之间的关系。 在我们团队合作的整个交流过程之中，当 Bob 认为其他人犯错时，他并没有强行去让他人接受自己的观点，也没有偏执地想要去在与他人的辩论中占据上风。但是他不停地提出问题，在别人回答这些问题的过程中，他们经常会发现自己也存在 Bob 提出的这些疑问。在于软件相关的几乎所有的决策过程中，我们几乎都会发现 Bob 所提出的问题的踪影。Bob 并没有就自己对团队的贡献而四处宣扬，也没有拿自己作为工程师的专业水平去压别人。他似乎并不介意自己在配对合作过程中有多久的时间是自己掌控键盘，占据主导地位。可以说他是我合作过的最优秀的一位工程师。 我学到的第二课：你影响他人的能力取决于你能否帮助他人、引导他人靠他们自己来推导出与你所做的相同的结论。 Bob 几乎从不说“我们就应该这样做，因为……”，他会就你们目前所考虑的一些想法提出几个问题，到你们讨论的最后，你会发现绝大多数情况下，他的问题都会引导其他人与他达成共识。Bob 并不是自己提出什么完美无暇的想法，通常情况下，他都是先提出几个问题，然后得到其他人的回答，其中一个问题的答案通常会实现这样的效果，就是让他说出“这是一个好点子，我们继续探究一下”类似这样的话。但是，就是这样的方式让他对我们的软件质量产生了最积极的影响，因为他拥有着影响我们团队成员推理过程和方向的强大能力。但是，他实现这一目的并不是通过直接分享他自己的想法，更多的是通过提问的方式来实现。 我学到的第三课：在开始考虑一个问题的解决方案之前，先提出许多的问题，这是一位优秀的问题解决者的标志。 作为软件工程师，我们的核心工作就是解决问题。学习新东西是一个需要解决的问题，编码是一个需要解决的问题，沟通也是一个需要解决的问题。优秀的软件工程师就是优秀的问题解决者，而要解决问题的一个好办法就是通过提出问题来理解问题。提出问题表明你尊重他人的想法，提出问题可以帮助你更好的理解事物，提出问题能够让你有更大的可能性得出获得他人认知的答案。最能提出解决方案的人往往就是那些愿意花时间去理解问题的那些人。 关于 Bob 的故事还有一点，他在技术方面很有天赋，完全可以成为团队主力和领军人物。如果他愿意，我相信他都可以成为一名设计师，只是他没有那个想法。Bob 喜欢写代码，他喜欢做域名分析，喜欢设计业务对象，喜欢编写测试套件，喜欢交付高质量的软件。 回顾 回首我做软件工程师的前两年可以说是一趟充满冒险的旅程。我不停地构建软件、破坏软件以及修复软件。我参加了好多无聊的会议，无聊到你真的可以趴在桌上睡着的那种程度。我闷头扎入工作的海洋，体会着其中的酸甜苦辣。 回看最开始的那两年的软件工程师时光，我发现自己有以下几点需要改进：
|
