我在 20 年的软件工程师生涯中学到的 20 件事

原文链接：20 Things I’ve Learned in my 20 Years as a Software Engineer

作者：贾斯汀·埃瑟瑞奇/ @JustinEtheredge /2021 年 10 月 7 日

重要，请先阅读此内容

您即将阅读一篇包含大量建议的博客文章 。向前人学习对成功至关重要，但我们常常忘记一个重要的注意事项。几乎所有的建议都是背景关联的，但它却很少在任何相关背景中被传递。

“你只需要收取更多费用！” 这家经营了 20 年的公司说，多年来收费“太低”，无法赢得客户并取得成功。

“你需要将一切构建为微服务！” 该公司表示，他们构建了一个快速的单体应用，获得了数千名客户，然后在开始遇到扩展问题时转向微服务。

如果不了解背景，这些建议就毫无意义，甚至更糟糕，这些建议是有害的。如果那些人早点听从他们自己的建议，他们自己很可能会因此而受苦。很难逃脱这个陷阱。很难逃脱这个陷阱。我们可能是经验的总结，但我们通过现在的视角来看待它们。

因此，为了给你介绍一下我的建议的来龙去脉，我的职业生涯的前半部分是作为一名软件工程师，为各种小企业和初创公司工作，然后我进入咨询行业，在一些真正的大企业工作。然后我创办了 Simple Thread，我们从一个 2 人的团队成长为一个 25 人的团队。10 年前，我们主要与中小型企业合作，现在我们与大型和小型企业合作。

我的建议来自于……

1. 几乎总是在小而精干的团队中，我们必须用很少的资源做很多事情。

2. 重视工作软件而不是特定工具。

3. 一直在启动新的项目，但同样也要维护一些系统。

4. 重视工程师的生产力胜过大多数其他考虑因素

我过去 20 年的经历塑造了我对软件的看法，并使我形成了一些信念，我试图将这些信念缩减成一个易于管理的清单，希望你能发现它们的价值。

在清单上

1.我还不是很了解

“你怎么可能不知道 BGP 是什么？” “你从未听说过 Rust？” 我们大多数人都听过这类说法，而且可能听得太频繁了。我们中的许多人喜欢软件的原因是因为我们是终身学习者，在软件领域中，无论您往哪个方向看，都有广阔的知识前景，而且日渐扩大与发展。

这意味着你可以在你的职业生涯中度过数十年，但与同样在看似相似的角色中度过数十年的人相比，仍然存在巨大的知识差距。你越早意识到这一点，你就能越早开始摆脱冒名顶替综合症，转而乐于向他人学习和教导他人。

2. 软件最难的部分是构建正确的东西

我知道这一点是老生常谈，但大多数软件工程师不相信的原因是他们认为这贬低了他们的工作。我个人认为这是无稽之谈。相反，它强调了我们必须在其中工作的环境的复杂性和不合理性，这使得我们的挑战更加复杂。

你可以设计出世界上技术上最令人印象深刻的东西，然后却没有人愿意使用它。这种情况一直在发生。设计软件主要是一种倾听活动，我们经常不得不成为部分软件工程师、部分心理学家和部分人类学家。在这个设计过程中的投资，无论是通过专门的 UX（用户体验） 团队成员还是通过简单的自我学习，都将带来巨大的回报。因为您如何真正计算出构建错误软件的成本？这不仅仅是损失的工程时间。

3. 最好的软件工程师像设计师一样思考

伟大的软件工程师会深入思考他们代码的用户体验问题。他们可能不会用这些专业术语来考虑它，但无论是外部 API、程序化 API、用户界面、协议，还是其他任何界面；优秀的工程师会考虑谁会使用它，为什么会使用它，如何使用它，以及什么对这些用户是重要的？

把用户的需求放在心上，确实是好的用户体验的核心。

4.最好的代码是没有代码，或者你不必维护的代码

我要说的就是“码农要编码”（coders gonna code.）。你问任何行业的人如何解决一个问题，他们都会从他们擅长的方面出发。这只是人类的天性。

大多数软件工程师总是倾向于编写代码，尤其是当非技术解决方案不明显时。对于不需要维护的代码也是如此。工程团队倾向于想要重新发明轮子，即使已经有很多轮子存在。这是一个平衡的行为，有很多理由去发展自己的东西，但要注意有毒的“非此即彼”（Not Invented Here）综合症。

5. 软件是达到目的的手段

任何软件工程师的主要工作都是交付价值。很少有软件开发人员理解这一点，将其内化的就更少了。真正将其内化会导致以不同的方式解决问题，并以不同的方式看待你的工具。如果你真的相信软件是从属于结果的，你就会准备好真正找到“适合工作的工具”，而这个工具可能根本就不是软件。

6. 有时候你需要停止磨刀，开始干活。

有些人倾向于跳入问题中并直接开始编写代码。另一些人往往则想要分析研究和再研究，并陷入分析瘫痪。在这些情况下，您需要为自己设定一个截止日期，然后开始探索解决方案。当你开始解决问题时，你会很快学到更多的东西，这将引导你迭代到更好的解决方案。

7. 如果你不能很好地把握世界的可能性，你就无法设计出好的系统

这是我一直在努力解决的问题，因为我的职责使我在软件工程的日常工作中越来越远。跟上开发者生态系统是一项巨大的工作，但了解什么是可能的至关重要。如果您不了解在特定的生态系统中什么是可能的，以及什么是可用的，那么您将发现除了最简单的问题之外，不可能设计出一个合理的解决方案来解决所有问题。

总而言之，对那些很久没有写过代码的系统设计者要保持警惕。

8. 每个系统最终都很糟糕，克服它

Bjarne Stroustrup （C++ 之父）有一句名言：“只有两种语言：人们抱怨的语言和没人使用的语言”。这也可以延伸到大型系统上。没有“正确”的架构，你永远无法偿还所有的技术债务，你永远无法设计出完美的界面，你的测试总是太慢。

这不是永远不把事情做得更好的借口，而是一种让你有所作为的视角。不要担心不够优雅和完美；相反，而是努力实现并持续改进，创建一个活跃的系统，让你的团队喜欢在其中工作，并可持续地提供价值。

9. 没有人能问够“为什么”

抓住任何机会，质疑“事情一直以来的做法 ”的假设和方法。有新的团队成员加入吗？注意他们在哪里感到困惑，以及他们问了什么问题。新功能的需求有没有意义？

确保您了解目标，以及是什么推动了对这一功能需求的渴望。如果您没有得到明确的答案，请继续问为什么，直到您明白为止。

10. 我们应该更专注于避免 0.1 倍的程序员而不是寻找 10 倍的程序员

10 倍程序员是一个愚蠢的神话。某人可以在 1 天内完成另一个有能力、勤奋、同样有经验的程序员可以在 2 周内完成的工作，这种想法是愚蠢的。我见过的程序员的代码量是其他程序员的 10 倍，而你需要修改的次数也是 10 倍。一个人成为 10 倍程序员的唯一方法是将他们与 0.1 倍程序员进行比较。那些浪费时间、不征求反馈意见、不测试自己的代码、不考虑边缘情况等的人......我们应该更关心如何让 0.1 倍的程序员离开我们的团队，而不是寻找神话中的 10 倍程序员。

11. 高级工程师和初级工程师之间最大的区别之一是他们已经形成了对事情应该如何发展的看法

没有什么比一个对自己的工具或如何构建软件没有意见的高级工程师更让我担心了。我宁愿有人给我强烈反对的意见，也不愿他们完全没有意见。如果您正在使用您的工具，而且你对它们不爱也不恨，那么您需要去体验更多，比如探索其他语言、库和范式。没有什么方法能比积极寻找别人如何用与你不同的工具和技术来完成相同任务，更快提高你的技能水平。

12. 人们并不真正需要创新

人们经常谈论创新，但他们通常寻找的是廉价的胜利和新奇。如果你真正地进行创新，并改变人们做事的方式，预计将会有大部分的负面反馈。如果您相信自己正在做的事情，并且知道它确实会改善一些事情，那么请做好准备迎接一场漫长的战斗。

13. 你的数据是你系统中最重要的一部分

我见过很多系统，它们都希望系统的主体保证数据完整性。在这样的系统中，任何在黄金路径之外发生的事情都会产生部分或脏数据。将来处理这些数据可能会变成一场噩梦。请记住，您的数据可能会比您的代码库长寿。花精力保持它的有序和干净，从长远来看，这将会有很好的回报。

14.寻找技术型鲨鱼

坚持下来的老技术是鲨鱼，而不是恐龙。它们很好地解决了问题，在技术世界不断发生的快速变化中幸存下来。不要对这些技术下赌注，只有在你有非常好的理由时才替换它们。这些工具不会是华而不实的，也不会是令人兴奋的，但它们会完成工作，不会有很多不眠之夜。

15. 不要把谦虚误认为是无知

有很多软件工程师除非被问到，否则不会发表意见。不要以为别人不在你面前发表意见，就认为他们没有什么可补充的。有时候，最吵的人是我们最不想听的人。与你周围的人交谈，寻求他们的反馈和建议。你会很高兴你选择这样做了。

16. 软件工程师应该定期写作

软件工程师应该定期写博客、写日记、写文档，总之做任何需要他们保持书面沟通能力的事情。写作可以帮助您思考问题，并帮助您更有效地与团队和未来的自己沟通。良好的书面沟通是任何软件工程师都需要掌握的最重要的技能之一。

17. 尽可能保持流程精简

现在每个人都想变得敏捷，但“敏捷”就是以小块的方式构建事物，学习，然后迭代。如果有人试图塞进比这更多的东西，那么他们可能是在推销东西。这并不是说人们不需要问责或帮助以这种方式工作，但您有多少次听到您最喜欢的科技公司或大型开源项目的人吹嘘他们的 Scrum 流程有多棒？保持精益过程，直到你知道你需要更多。相信您的团队，他们会交付成果。

18. 软件工程师和所有人一样，需要有归属感

如果你把某人从他们的工作成果中分离出来，他们就会减少对他们工作的关心。我认为这几乎是一个同义词。这是为什么跨职能团队工作得如此出色以及 DevOps 变得如此流行的主要原因。这不仅仅是关于交接和效率低下，而是关心从头到尾拥有整个流程，并直接负责交付价值。让一群充满激情的人完全拥有设计、构建和交付软件（或任何东西）的权利，令人惊奇的事情就会发生。

19. 面试对于判断一个人将成为多好的团队成员几乎毫无价值

面试最好是用来了解某人是谁，以及他们对某一专业领域的兴趣如何。试图找出他们将是一个多么好的团队成员是一个没有结果的努力。相信我，一个人有多聪明或知识渊博，也不是一个很好的指标，说明他们会成为一个伟大的团队成员。没有人会在面试时告诉你，他们会不可靠、滥用职权、华而不实，或者从不按时出席会议。人们可能会声称他们对这些事情有 "信号"...... "如果他们在第一次面试时问起休息时间，那么他们就永远不会去了！" 但这些都是胡说八道。如果你使用这样的信号，你只是在猜测和拒绝好的候选人。

20.始终努力构建一个更小的系统

有很多力量会促使您预先构建更大的系统。预算分配，无法决定应该削减哪些功能，希望提供系统的“最佳版本”。所有这些事情都非常有力地推动我们建立过多的系统。你应该与此斗争。您在构建系统时学到了很多东西，您最终会迭代到一个比您最初设计的更好的系统。令人惊讶的是，这对大多数人来说是难以接受的。

你的故事是什么？

所以，你有了它，20 年的软件提炼成 20 条精辟的智慧。如果有什么能引起你的共鸣，我很想听听。我也很想听听您是否有在您的职业生涯中积累的智慧，并愿意与人分享。欢迎在评论中留言。