作者：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. 最佳代码是不写代码，或无需维护的代码

我只想说一句：“程序员终究还是要写代码的。”

你问任何一个职业的人该怎么解决问题，他们往往都会偏向于用自己擅长的方式去做——这是人性使然

对大多数软件工程师来说，他们天然地倾向于通过写代码来解决问题，尤其是在非技术方案并不明显的时候。同样的道理，也适用于那些他们不需要亲自维护的代码。

工程团队往往容易陷入重新造轮子的冲动，哪怕世界上已经有了很多现成的轮子。当然，有时候自己造一个新轮子确实有充分的理由——但要当心那种有毒的“非我发明”（Not Invented Here）综合症

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

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

任何软件工程师的首要职责，都是创造价值。但真正明白这一点的人很少，能真正将其内化于心的人更是寥寥无几。

一旦你真正理解并践行这一理念，你解决问题的方式、看待工具的角度都会随之改变。

如果你真心相信软件只是实现目标的手段，而不是目的本身，那么你就能真正做到 “为任务找到最合适的工具”，而这个工具——有时甚至根本不是软件

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

有些人喜欢一头扎进问题，就开始写代码；而另一些人则容易陷入不断研究、分析过度的状态，也就是所谓的“分析瘫痪”。

遇到这种情况时，给自己设定一个截止时间，然后开始探索解决方案**。

当你真正动手去解决问题时，你会快速学到更多，并且能通过不断迭代，最终找到一个更好的解决方案。

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

这是我自己也经常面临的一个挑战——随着职责越来越偏离日常的软件开发，保持对开发者生态的了解变得越来越困难。

紧跟开发生态确实需要投入大量精力，但了解可能性是至关重要的。

如果你不了解在特定生态中什么是可行的、什么工具是可用的，那么除了最简单的问题之外，你几乎无法设计出合理的解决方案

总结一句话：要对那些很久没有写过代码却在设计系统的人保持警惕。

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

Bjarne Stroustrup 曾说过一句话：

“编程语言只有两种：一种是大家抱怨的，另一种是没人用的。”

这句话同样适用于大型系统。

没有所谓的“完美架构”，你永远无法清理掉所有技术债务，永远无法设计出完美的接口，你的测试总会显得太慢。

这并不是说我们可以不去改进，而是提醒你要保持正确的心态：

不要过分追求优雅与完美，而应专注于持续改进，创建一个可用、可持续、团队喜欢工作并能稳定产出价值的系统

9. 永远多问为什么

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

有新成员加入团队吗？关注他们困惑的地方和提出的问题。

收到一个看似不合理的新功能需求吗？务必弄清楚背后的目标以及推动这个需求的原因。

如果你还没有得到清晰的答案，就不断追问“为什么”，直到真正理解为止。

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

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

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

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

没有什么比一个对自己的工具或软件开发方法毫无看法的高级工程师更让人担忧。我宁愿有人提出你强烈反对的意见，也不愿他们完全没有任何意见。

如果你在使用工具时，既不爱也不恨它们，那说明你需要更多的实践和体验。你需要去探索其他语言、库和编程范式。

积极去了解别人如何用不同的工具和技术完成任务，几乎是提升技能最快的方式之一。

12. 人们其实不想要创新

人们总是在谈论“创新”，但他们真正追求的往往只是廉价的胜利和新奇的点子

如果你真正做出了创新，改变了人们必须做事的方式，那么你要做好心理准备——迎接的很可能是大量的负面反馈

但如果你坚信自己正在做的事情，并且知道它确实能带来改进，那就准备打一场持久战吧

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

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

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

14. 寻找技术界的鲨鱼

那些经久不衰的旧技术并不是恐龙，而是鲨鱼

它们之所以能在瞬息万变的科技世界中长期存活下来，是因为它们解决问题的方式极其高效而稳健

不要轻易低估这些技术，除非你有非常充分的理由，否则不要轻易替换它们

这些工具也许不够华丽、也不够令人兴奋，但它们能可靠地完成工作，让你少熬很多个不眠之夜

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

15. 别把谦逊当无知

许多工程师不主动表达观点。别因此低估他们的价值。

最喧哗的人往往最不值得倾听。主动征求周围人的建议，你会受益良多

16. 软件工程师应该坚持写作

软件工程师应该经常写博客、记笔记、撰写文档，或者做任何能让自己保持文字表达能力敏锐的事情

写作能帮助你更深入地思考问题，也能让你更有效地与团队成员沟通，甚至与未来的自己沟通

良好的文字表达能力，是每一位软件工程师都应当掌握的最重要技能之一

17. 流程要尽可能精简

如今人人都在谈“敏捷”，但真正的敏捷其实只是：将事情分解为小块去做、从中学习、然后不断迭代

如果有人试图往这个概念里塞进更多花哨的东西，那他们多半是在兜售某种东西

这并不是说团队不需要规范或外部帮助来实现这种工作方式，但想一想——你有多少次听过你最喜欢的科技公司或大型开源项目的成员在炫耀他们的敏捷流程多么完美？答案可能是：几乎没有

在你真正需要更多流程之前，尽量保持流程精简

相信你的团队，他们会交出成果。

18. 软件工程师需要拥有感

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

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

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

20. 永远追求更小的系统

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

你的故事是什么？

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