20年老程序员的20条至理名言

悠悠 2022-09-16 00:20 191阅读 0赞

点击上方关注 前端技术江湖，一起学习，天天进步

> 转自：机器之心

> 任何人都可以写代码，但并不是所有人都适合写代码。

近日，新闻网站 Hacker News 一个帖子可谓火爆，该贴内容讲的是一位有 20 年软件经验的工程师，学到的 20 件事。

![2bf6c7f82769bf2907f3479341961fff.png][]

如果你在科技领域工作多年，有什么对后来人要说的话？这篇文章中包含 20 条建议，许多建议都是来自他人的一些经验总结。文章作者 Justin Etheredge 工作经历可谓丰富，他的职业生涯中前半部分是软件工程师，为各种小型企业和初创公司工作，然后进入咨询行业并在许多真正的大型企业中任职。之后 Justin Etheredge 职业发展良好，团队从 2 人发展到 25 人。10 年前，Justin Etheredge 主要与中小型企业合作，现在他们与大型和小型企业合作。

这 20 条建议主要来自以下这些人的经验总结：

*  那些几乎总是在小的、精益的团队中工作的人，因为他们能用很少的资源做更多的事情；
 *  那些重视工作软件开发而不是特定工具的人；
 *  那些一直都在开展新的项目，而且还要兼顾维护一些其他系统的人；
 *  那些将工程师的生产力当作第一要务，置于其他工作之上的人。

Justin Etheredge 表示，自己在过去 20 年的经历塑造了他对软件的看法，并产生了一些信念，他试图将这些信念缩减为一个可管理的列表，希望这些建议能给别人带来价值。

**Justin Etheredge 的 20 条经验分享**

**1. 我还是什么都不懂**

我们中的大多数人可能都会频繁听到类似这样的话，「你怎么会不知道什么是 BGP？你从没听说过 Rust？」我们中的许多人喜欢软件的原因是因为我们是终身学习者，在软件领域，无论你朝哪个方向发展，都有广阔的知识视野向各个方向传播，并且发展方向每天都在扩展。这意味着你可以在职业生涯中度过几十年，但与在看似相似的角色上也花了几十年的人相比，软件领域的人仍然存在巨大的知识差距。你越早意识到这一点，你就可以越早摆脱冒名顶替综合症，而是乐于向他人学习和教导他人。

**2. 软件最困难的部分是构建正确的内容**

大多数软件工程师不相信这一点的原因是因为他们认为这贬低了自己的工作。然而相反的是，恰恰是这一点突出了软件工程师工作环境的复杂性和非理性，这进一步加剧了软件工程师的挑战。你可以设计出在技术上最令人惊叹的东西，然而糟糕的是，最后没人愿意使用它。这种事情无时无刻不在发生。设计软件主要是一种倾听需求的活动，通常我们必须兼任软件工程师、聆听者和人类学家的身份。专注于这个设计过程，无论是通过专门的 UX 团队成员还是通过简单的自我教育，都将带来巨大的回报。

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

伟大的软件工程师会深入思考他们所写代码的用户体验。例如外部 API、编程 API、用户界面、协议还是其他接口， 优秀的软件工程师会考虑谁将使用他们的研究、为什么使用它、如何使用以及对这些用户来说什么是重要的。牢记用户需求才是良好用户体验的核心。

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

编程人员需要会编程。大多数人都会在自己擅长的方面犯错，这是人的本性。很多软件工程师经常在编写代码方面犯错，尤其是当非技术解决方案不明显时。无需人员维护的代码也是如此。当很多算法已经存在时，工程团队很容易想要开辟新的方法，这是一个平衡的行为。

有很多理由让你重新发明轮子，但需要注意的是「非原创」并不在其中。

**5. 软件是达到目的的一种手段**

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

**6. 为自己设定截止日期**

有些人倾向于深入问题并开始编写代码，而有些人只想研究理论，没有着手代码，进而让自己陷入困难的漩涡。在这些情况下，为自己设定一个截止日期，然后开始探索解决方案。当你开始解决问题时，你会很快学到更多，这将引导你迭代到更好的解决方案。

**7. 如果你不能很好地把握可能发生的一切，你就不能设计一个好的系统**

与开发者生态系统进展保持一致是一项巨大的工作，了解生态系统中哪些是至关重要的，如果你不了解给定生态系统中哪些是可能的，哪些是可用的，那么除了能发现最简单的问题之外，你不可能为所有问题设计一个合理的解决方案。总而言之，你要警惕那些很长时间没有编写任何代码设计系统的人。

**8. 每个系统都会很糟糕，你需要克服**

Bjarne Stroustrup 有一句名言：只有两种语言，即人们抱怨的语言和没人使用的语言。这一名言可以扩展到大型系统。如果没有正确的软件架构，你永远无法偿还所有的技术债务，你永远无法设计出完美的界面。尽量少担心系统的优雅和完美， 相反，要努力持续改进你的系统，并创建一个团队喜欢在其中工作的适宜系统，并可持续地提供价值。

**9. 多问为什么**

抓住任何机会进行询问。例如「有新的团队成员加入吗？注意他们在哪里出现混淆以及他们问的什么问题。有一个没有意义的新功能请求？」等等这些看似不起眼的问题。确保自己了解目标以及推动此功能需求的因素。如果你没有得到明确的答案，请继续问为什么，直到明白为止。

**10. 程序员大神都是传说**

寻找工作效率能达到 10 倍的程序员是不可取的。那些所谓的一个人可以在 1 天内完成另一个程序员（有能力、努力工作、同样有经验的）在 2 周内完成的想法是愚蠢的。假如程序员抛出 10 倍数量的代码，那么你需要 10 倍数量的精力修复它。一个人成为 10 倍程序员的唯一方法是将他们与 0.1 倍程序员进行比较。一个浪费时间、不寻求反馈、不测试代码、不考虑边缘情况等的人…… 我们应该更关注的是让 0.1 倍的程序员远离我们的团队，而不是寻找神话般的 10 倍程序员。

**11. 工程师需要更多的建议**

最让人担心的是没有人对高级工程师构建的软件提出意见，相反的，他们宁愿希望有人提出强烈的反对意见，也不愿别人根本没有意见。如果你正在使用某个工具，你需要更多的体验才能知道这个工具的优势和劣势，对于劣势，你可能需要探索其他语言、库和范式才能解决。除了积极寻找别人是如何使用不同的工具和技术完成任务之外，没有什么方法能更快地提升你的技能。

**12. 你根本不懂什么是创新**

人们经常谈论创新，但他们通常寻找的是廉价的胜利。如果你真的在创新，并改变了人们做事的方式，那么你应该期待负面的反馈。如果你相信你正在做的事情，并知道它真的会改善一些事物，那么你需要准备好迎接一场长期的战斗。

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

对于许多程序员来说，数据是系统中最重要的部分。在这样的系统中，发生在黄金路径之外的任何操作都会产生脏数据。将来处理这些脏数据可能会变成一场噩梦。请记住，数据可能会比代码库存在时间更长。花精力保持数据的有序和清洁，从长远来看，你会得到很好的回报。

**14. 寻找技术「鲨鱼」**

一直存在的旧技术可看作「鲨鱼」，而不是「恐龙」。这些旧技术很好地解决了问题，以至于在不断快速变化的技术世界中幸存下来。但是请不要随意替换这些技术，只有在有充分理由的情况下才替换它们。这些技术不会花哨，也不会令人兴奋，但它们会在很多情况下完成工作。

**15. 不要误以为谦卑就是无知**

很多软件工程师不会发表意见，除非被要求才会提出意见。不要以为别人不发表自己的观点就没有什么可补充的。有时候，最聒噪的人恰恰是我们最不想听的人。和你周围的人交谈，寻求他们的反馈和建议。你会庆幸你这么做了。

**16. 软件工程师应该定期记录研究**

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

**17. 让过程尽可能的精简**

如今，每个人都想变得敏捷，但敏捷是通过构建小块的东西，然后学习、迭代完成的。如果有人想把更多的东西塞进去，这是不可取的。在工作中，你很少听到科技公司或大型开源项目吹嘘他们的 Scrum 流程有多棒？在工作中保持精益求精。

**18. 软件工程师需要有主人翁的感觉**

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

**19. 面试对于说明一个团队成员的优秀程度几乎没有价值**

面试的意义在于了解他 / 她是谁，以及他们对于特定专业领域的兴趣程度。而面试「原本该有」的意义，试图了解他们是否能够成为一个优秀团队成员的努力都是徒劳的。相信我，一个人的聪明或博学程度和他是否能够在团队中做到贡献没有太大关系。没有人会在面试中告诉你，他们会不可靠、随便骂人、自负或从不准时出席会议。

有人可能会声称他们可以在面试中看出端倪「如果他们在第一次面试中询问休息时间，那就要小心了。」但这些都是胡说八道。如果你使用这样的信号作为评判标准，你只是在猜测并拒绝优秀的候选人。

**20. 小即是美**

有很多力量会促使你预先构建更大的系统。要求更多的预算，无法决定削减哪项功能，希望提供系统的「最佳版本」，所有这一切都在推动我们构建过多，但你应该为反对这种趋势而战。构建一个系统地时候，你会学习到很多东西， 这会和你当初的设想大为不同。但对于很多人来说，以最好为目标是很难的。

老程序员的这些建议或许可以为你带来一些帮助。在成为一名开发者之后，你是否也有踩过的坑，或者总结出来的经验？

*原文链接：*

*https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/*

The End

欢迎自荐投稿到《前端技术江湖》，如果你觉得这篇内容对你挺有启发，记得点个 **「在看」**哦

点个『在看』支持下 ![48d8a95fa156da006f0d515d8a2ea453.gif][]

[2bf6c7f82769bf2907f3479341961fff.png]: /images/20220828/9298317abac64ac6a7858ada8040c60f.png
[48d8a95fa156da006f0d515d8a2ea453.gif]: /images/20220828/b4ec6b7f09ed4776ad37fbde56e9e523.png