翻译自：20 Things I’ve Learned in my 20 Years as a Software Engineer

我知道的很少

“你竟然不知道 BGP 是什么？” “你从没听过 Rust？” 我们大多数人都听说过这种说法，甚至频繁听到。我们许多人喜欢编程是因为我们是终身学习者，在编程领域无论往哪个方向都有广阔的知识前景，并且每天都在扩展。这意味着即使你度过了几十年的职业生涯，与那些在看似相似的角色中度过了几十年的人相比，仍然有巨大的知识差距。越早意识到这一点，你就能越早开始摆脱你的冒充者综合症，转而乐于向别人学习和教导别人。

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

我知道这在这一点上是陈词滥调，但大多数软件工程师不相信它，因为他们认为这是贬低他们的工作。我个人认为这是无稽之谈。相反，它突出了我们的工作环境的复杂性和不合理性，这使我们的挑战更加复杂。你可能可以设计出世界上最令人印象深刻的技术，但是没有人愿意使用它。这无时无刻不在发生。设计软件主要是一种倾听活动，我们经常必须部分是软件工程师，部分是通灵者，部分是人类学家。投资这个设计过程，无论是通过专门的用户体验团队成员还是简单地自我学习，都将带来巨大的红利。因为错误的软件的成本是无法计量的，损失的不仅仅是工程花费的时间。

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

优秀的开发者会更加注重用户的体验。不管是对外的 api、编程式的 api、用户界面、协议还是其他任何形式的接口，优秀的开发者总会考虑他们的目标用户是哪些、使用的意义是什么、是怎么被使用的、用户在意的是什么。关注用户需求才是提升用户体验的核心。

最好的代码是没有代码，或者不需要维护的代码

我只能说“程序员写代码”。你问任何职业的人如何解决问题，他们都会在他们擅长的事情上犯错。这只是人类的天性。大多数软件工程师总是会在编写代码方面犯错，尤其是隐约需要非技术的解决方案时。不需要维护的代码也是。工程团队倾向于重新发明轮子，即使已经存在很多轮子。这是一种平衡行为，自己造轮子的理由可以有很多，但要小心有毒的“非此创造”综合症。

软件是达到目的的手段

软件工程师的主要工作都是提供价值。很少有软件开发人员了解这一点，深入骨髓的更少。真正理解这一点的人，会发现解决问题的不同方法，会从不同的角度审视自己的工具。如果你深信软件是为了结果，那么你将找到“正确的工具”，那可能根本不是软件。

有时你必须停止磨锯，开始切割狗屎

有些人倾向于跳入问题之中，然后开始编写代码。其他人倾向于研究再研究，并陷入分析瘫痪。这种情况，就要为自己设定一个截止日期，然后开始搜索解决方案。当开始解决问题时，你将很快了解更多信息，这将引导你迭代到更好的解决方案。

如果不能掌握无数的可能性，就无法设计一个好的系统

这是我一直在努力的事情，因为我的职责使我日常的编程工作中越来越远。跟上开发者生态系统的步伐是一项艰巨的工作，但了解可能性至关重要。如果你不了解给定生态系统中可能发生什么、有什么可用工具，那么你就会发现除了最简单的问题之外，不可能为所有问题设计一个合理的解决方案。总而言之，要警惕那些长时间没有编写任何代码的系统设计师。

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

Bjarne Stroustrup 有一名言：“只有两种语言：人们抱怨的语言和没有人使用的语言”。这也可以扩展到大型系统。没有“正确”的架构，你永远无法偿还所有技术债务，你永远不会设计出完美的界面，你的测试总是太慢。这不是不思改进的理由，而是给你一种切换视角的方式。少担心点优雅和完美;相反，努力持续改进，为团队创建一个好的环境，持续地提供价值。

多问“为什么”

抓住一切机会质疑“一直都是这么做的”。有新的团队成员加入吗？注意他们感到困惑的地方以及他们问的问题。有没有无意义的新功能需求？确保您理解目标以及需求的由来。如果你没有得到一个明确的答案，继续问为什么，直到你明白为止。

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

10x 程序员是一个愚蠢的神话。这个想法是愚蠢的：有人可以在 1 天内生产出另一个有能力、勤奋工作、经验相似的程序员在 2 周内的产出。我见过程序员抛出10倍的代码量，然后你必须花费十倍的时间来修复它。有些人浪费时间、不要求反馈、不测试代码、不考虑边界情况等... 我们应该更关心的是让团队中避免 0.1x 程序员，而不是找到神话般的 10x 程序员。

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

我很担心高级工程师对他们的工具或如何处理构建软件没有意见。我宁愿有人提出强烈不同意的意见，也不愿他们根本没有意见。如果你说不出你的工具的很多优点和很多缺点，你需要体验更多。你需要探索其他语言、库和范式。积极向他人学习看看其他人如何使用不同的工具和技术完成任务，可以快速提升你的技能。

人们并不真正想要创新

人们经常谈论创新，但他们的目的通常是便捷性和新鲜感。如果你真的在创新，并改变了人们做事的方式，那么大多会得到负面的反馈。如果你深信你正在做的事情真的有意义，那么就准备好迎接一场长期的战斗。

数据是系统中最重要的部分

我见过很多以数据完整性为最重要目标的系统。在这样的系统中，黄金路径之外发生的任何事情都会造不完整或脏数据。将来处理这些数据可能是一场噩梦。请记住，数据的生命周期可能比代码仓库还要长。花费精力保持数据的秩序和整洁，从长远来看会得到很好的回报。

寻找技术鲨鱼

一直存在的旧技术是鲨鱼，而不是恐龙。他们很好地解决了问题，从而在不断快速迭代的技术世界中幸存了下来。不要反对这些技术，只有在你有充分的理由时才去更换它们。这些工具不会华而不实，也不会令人兴奋，但它们不会让你为了完成工作而天天晚上加班。

不要把谦卑当作无知

有很多软件工程师除非被问到，否则他们不会发表意见。永远不要认为仅仅因为有人没有把他们的意见甩到你的脸上，他们就没有什么可补充的。有时候，最吵的人是我们最不想听的人。多与周围的人交谈，寻求他们的反馈和建议，会对你很有好处。

软件工程师应该定期写作

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

尽可能保持流程精简

如今，每个人都想变得敏捷，“敏捷”就要以小的单位构建东西，学习，然后迭代。如果有人试图把更多的东西塞进去，那么他们可能正在卖东西。这并不是说人们不需要问责制或帮助来工作，但是你有多少次听到你最喜欢的科技公司或大型开源项目的人吹嘘他们的Scrum流程有多棒？保持流程的精简，直到你确认自己需要更多。相信你的团队，他们会做到的。

软件工程师和所有人一样，要有主人翁意识

如果你不关注员工的工作产出，他们就会不那么关心他们的工作。这就是为什么跨职能团队工作得如此出色，以及为什么DevOps变得如此流行的主要原因。这不仅仅是关于交接和低效率，而是关于从头到尾掌握整个过程，并直接负责交付价值。让一群充满激情的人完全拥有设计、构建和交付一个软件（或任何真实的东西）的所有权，就会发生令人惊叹的事情。

面试几乎毫无价值，无法说明一个人会成为多好的团队成员

面试最好花在试图了解某人是谁，以及他们对特定专业领域的兴趣程度上。试图确定他们将是一个多么优秀的团队成员是徒劳的努力。相信我，一个人有多聪明或知识渊博，也不是他们将成为优秀团队成员的好指标。没有人会在面试中告诉你，他们会不可靠、辱骂、自负，或者永远不会按时出席会议。人们可能会声称他们对这些事情有“信号”… “如果他们在第一次面试中问到休假时间，那么他们就永远不会去了！”但这些都是废话。如果你使用这样的信号，你只是在猜测并拒绝好的候选人。

始终努力构建更小的系统

有很多力量会推动你提前构建更大的系统。预算分配，无法决定应该削减哪些功能，渴望提供“最佳版本”的系统。所有这些事情都强烈地推动我们建设太多。你应该反对这种情况。在构建一个系统的过程中，你学到了很多东西，最终你会迭代到一个比最初设计的要好得多的系统中。对于大多数人来说，这是一个出人意料的卖点。