作者：Justin Etheredge

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

重要提醒：请先阅读这部分

您即将阅读的这篇博客包含大量建议。向行业前辈学习固然是成功的关键，但我们常常忽略一个重要前提——几乎所有建议都依赖于特定背景，而提供建议的人却很少交代这些背景。

“你只需要提高定价！”

—— 说这话的公司已经营 20 年，当年正是靠"低价策略"积累客户才获得成功

“所有系统都应该用微服务架构！”

——给出这个建议的企业最初快速开发了单体应用，获得数千客户后遇到扩展性问题，才转向微服务

脱离背景的建议毫无价值，甚至可能有害。如果这些成功者早年就遵循自己现在给出的建议，他们很可能反受其害。这个认知陷阱很难避免——我们虽是过往经历的集合体，却总是用现在的视角解读它们。

为了让您理解我建议的背景：我职业生涯前半段是在各类中小企业担任软件工程师，之后进入咨询领域服务多家大型企业。后来创办 Simple Thread 时团队从 2 人发展到 25 人。10 年前我们主要服务中小客户，如今则大小客户兼有。

我的建议来自这样的视角：

  • 几乎始终在精干的小团队工作，必须用有限资源完成多项任务
  • 重视可运行软件胜过特定工具
  • 既频繁启动新项目，又需要维护多个现有系统
  • 将工程师效率视为首要考量

过去 20 年的经历塑造了我的软件观，也形成了一些核心观点。我已尽力将其浓缩成这份清单，希望对您有所帮助。

以下是我的建议清单：

1. 学无止境才是常态

“你居然不懂 BGP？““没听说过 Rust？“这种质问我们听得太多了。热爱软件行业正因为这是终身学习的过程——无论望向哪个方向，知识的疆域都在无限延伸。即便从业数十年，你与同辈人之间仍会存在巨大知识鸿沟。越早明白这点，就越快摆脱冒名顶替综合征，转而享受与他人互相学习的乐趣

2. 软件最难的是做正确的事

（虽然已成陈词滥调）很多工程师不愿承认这点，觉得会贬低自身价值。恰恰相反，这正凸显了我们工作环境的复杂性与非理性。你可以做出技术惊艳的作品，却无人问津——这种事每天都在发生。

软件开发本质是倾听的艺术，我们需要兼具工程师、心理学者和人类学家的视角。在设计流程投入资源（无论是组建用户需求团队还是自我提升）都将获得巨大回报。毕竟，开发错误软件的成本岂止是浪费工程时间？

3. 优秀工程师都有设计师思维

杰出的工程师会深度思考代码的用户体验——不论是外部 API、编程接口、用户界面还是协议设计。他们会考虑：使用者是谁？使用场景？核心需求？牢记用户需求才是优秀体验的本质

4. 最佳代码是不写代码，或无需维护的代码

职业惯性使然：人们总用擅长的方式解决问题。工程师自然倾向编码，尤其在非技术方案不明显时。同样，现有轮子无数，团队却总想重造。这需要平衡——自有开发虽有其价值，但要警惕"非我发明"综合征(NIH syndrome)的毒害

注解： NIH Syndrome（即 Not Invented Here Syndrome，直译为“非我所发明的”症候群）是一种心理现象，指的是人们或团队对外部资源、解决方案或技术的抵触情绪，倾向于只接受自己或自己的组织内部所发明或开发的事物，而排斥外部的创新或成果

5. 软件只是实现目标的手段

软件工程师的核心使命是交付价值，但鲜有人真正理解这点。彻底领悟后，你解决问题和选择工具的方式都会改变。当软件真正服务于目标时，你会发现"最适合的工具"可能根本不是代码

6. 有时必须停止磨刀，直接砍柴

有人喜欢立即编码，有人陷入分析瘫痪。**给自己设定截止期限，先探索解决方案。**动手过程中获得的认知，将引导你迭代出更好的方案

7. 不了解技术全景，无法设计好系统

随着职责变化，我越发体会这点。跟进开发生态是艰巨但必要的工作。若不清楚技术可能性，除了最简单的问题外，你都难以设计合理方案。简言之：警惕那些很久不写代码的系统设计者

8. 所有系统终将变糟，接受它吧

Bjarne Stroustrup（C++ 创造者）说过：

“语言只有两种：被人抱怨的和没人用的”

系统亦然。没有"完美"架构，技术债永远还不清，测试永远不够快。这不是放弃改进的借口，而是提醒我们：比起追求优雅完美，持续改进、构建可持续交付价值的宜居系统更重要

9. 永远多问"为什么”

质疑"一直都是这样"的做法。

新成员加入？留意他们的困惑点。接到不合理需求？追问背后的目标和动机。没有清晰答案？持续追问直到理解本质。

10. 应该警惕 0.1 倍效能的程序员，而非寻找 10 倍效能的

10 倍效率的程序员是一个荒谬的神话

有人一天产出相当于别人两周？我只见过写出 10 倍代码量，然后需要 10 倍时间修复的人。所谓 10 倍效能，只是相对于 0.1 倍效能者而言——那些不测试代码、不考虑边界条件、拒绝反馈的人。与其寻找神话，不如杜绝团队出现低效成员。

11. 高级工程师的核心特质：形成技术观点

最令人担忧的是没有技术主张的高级工程师。

宁可接受激烈反对的观点，也好过毫无主见。如果你对所用工具没有爱憎，说明阅历尚浅。尝试更多语言、库和范式——这是最快的成长方式

12. 人们其实不想要创新

大众追求的常是廉价胜利和新奇感。真正的创新往往招致负面反馈。若你确信改进价值，请准备持久战

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

见过太多依赖"希望"维持数据完整性的系统。一旦偏离理想路径，就会产生脏数据。

记住：数据往往比代码存活更久。保持其整洁有序，长远回报巨大

14. 寻找技术界的"鲨鱼”

历久弥坚的技术是鲨鱼而非恐龙。它们经受了技术浪潮的考验。

除非有充分理由，否则不要替换这些不炫酷但可靠的工具

15. 别把谦逊当无知

**许多工程师不主动表达观点。别因此低估他们的价值。**最喧哗的人往往最不值得倾听。主动征求周围人的建议，你会受益良多

16. 工程师应该坚持写作

无论是博客、文档还是笔记，写作能提升你的思维和沟通能力。这是工程师最重要的技能之一

17. 流程要尽可能精简

真正的敏捷是小步快跑、持续迭代。当有人鼓吹复杂的"敏捷"流程时，他们多半在兜售私货。优秀的科技公司或者开源项目有几个吹嘘 Scrum 流程？信任团队，保持精简

18. 工程师需要拥有感

剥夺工作成果的拥有感，就会削弱投入热情。跨职能团队和 DevOps 流行的核心原因正在于此——全程参与才能激发创造力。让 passionate 的团队完全拥有从设计到交付的全过程，奇迹自会发生

19. 面试几乎无法预测团队合作能力

面试应该用于了解候选人的专业兴趣领域。试图评估团队合作能力是徒劳的——聪明才智不等于团队价值。没人会在面试中承认自己将迟到、傲慢或不可靠。那些所谓的"信号"多是偏见，只会让你错失优秀人才

20. 永远追求更小的系统

**预算分配、难以割舍功能、追求"完美版本”——这些都在诱惑我们过度设计。必须抵抗！**系统构建过程中获得的认知，将引导你迭代出远超初期设计的方案。可惜多数人很难理解这点

你的故事是什么？

以上，是我二十年编程生涯凝练出的 20 条经验之谈。如果你对某条深有共鸣，或是想分享自己职业生涯中领悟的心得，欢迎在评论区留言交流——我很期待听到你们的故事。