译自：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. 最好的代码是没有代码，或者不需要你维护的代码
我想说的是“会写代码就会去写代码”。你去问任何一个行业的人如何解决问题，他们都会倾向于用自己擅长的方式解决，人性如此。大部分软件工程师在面临问题时，当非技术的解决方案不明显时，往往倾向于写代码解决问题。对你不需要维护的代码是一样的。工程师往往倾向于造轮子，哪怕已经有很多轮子了。这是一种权衡的艺术，有很多原因你可以自己造轮子，但是一定要避免
“非自家研发综合征”。
5. 软件是达到目的的手段
任何一位软件工程师，他的主要职责都是提供价值。很少有开发者能理解这一点，更少的人能够内化这一点。真正内化这一点以后，你就能用不同的方式解决问题，用不同的视角看待你的工具。如果你真的相信软件是为了达成某种目的而存在的，那你就会去为完成任务寻找最合适的工具，即使这个工具根本不是软件。
6. 有时候你必须停止磨刀，动手砍开屎山
有些人倾向于立即动手解决问题，直接开始写代码。有些人倾向于不停地研究、分析和思考，并且深陷其中。在这种情况下，你可以给自己定一个截止日期，然后开始你的探究分析。当你开始动手解决问题时，你会更快地学到更多的东西，这会引导着你不断优化已有地方案。
7. 如果你不能掌握所有的可能性，你就不能设计一个好的系统
随着我的工作职责日渐远离具体的软件开发，我遇到了这个难题。了解开发者的生态是一项巨大的任务，理解其中的可能性至关重要。在一个给定的开发生态里，如果你不了解其中可能的选择和可用的东西，那你几乎无法设计出合理的解决方案，除非是很简单的问题。总之，当心那些很久不写代码的人设计出来的系统。
8. 每个系统最后都会变得一团糟，接受这一点
Bjarne Stroustrup有一句名言：“只有两种编程语言：人们抱怨的语言和没人用的语言”。这句话也适用于大型软件系统，没有所谓“正确”的架构，你永远无法偿还所有的技术债务，你不可能设计出完美无缺的接口，你的测试始终跟不上开发的节奏。但这些都不是摆烂的借口，只是给你提供一种视角。不要过于追求优雅和完美，但是需要追求改进和提高，搭建一个让你的团队乐在其中并且能持续提供价值的系统。
9. 所有人的“为什么”都不够
质疑所有的“一直以来都是这样”的事。近期有新员工加入团队吗？看看他会卡在什么地方，会提出什么样的问题？提交PR的需求不合理吗？确保你真的理解了目标，理解了为什么要推动这个功能需求。如果你没有理解，那你就不断地问为什么，直到你理解为止。
10. 我们应该强调远离0.1x程序员，而不是寻找10x程序员
“10x程序员”是一个愚蠢的神话。认为某人能在1天内，能完成另外一个有能力、努力工作、经验相近的程序员在2周内完成的工作，本身就很荒谬。我确实见过能编写10倍数量代码的程序员，然后你就要修复10倍以上的问题。某些人如果被称为10x程序员，那也只能是和0.1x程序员对比，说的就是那些浪费时间、不请教问题、不寻求反馈、不测试代码、不考虑边界条件等的这些人。我们应该关注让这些0.1x程序员远离我们的团队，而不是寻找荒谬的10x程序员。
11. 资深工程师和初级工程师的最大区别之一，是他们对事情应该是怎么样有自己的观点
一个资深工程师对于开发工具以及如何构建软件没有自己的观点，没有比这更糟的事了。我宁愿有人提出我会强烈反对的观点，也不愿意他们毫无观点。如果你在使用工具时，没有在许多方面都对工具不满意，说明你要积累更多的经验。你要探索更多的编程语言、库和范式。通过主动了解其他人解决问题、完成任务的工具和技术，可以大幅提高你的技术水平，其他方式很难与之媲美。
12. 人们并不是真的想创新
人们经常讨论创新，但是他们追求的往往是廉价的新颖。如果你真的在创新，你就会改变人们的做事方式，这个时候你要准备好接受大量的负面反馈。如果你相信你做的事，并且坚信它是有益的，那就准备好打持久战！
13. 你的数据是系统中最重要的部分
我见过很多系统，它们维持数据完整性只靠美好的愿望。在这样的系统中，偏离最佳路径的任何操作都会引入脏数据，在未来脏数据的处理会是一场噩梦。请记住，数据大概率比你的代码更长寿。花时间保证数据的整洁和清晰，长期看来很有价值。
14. 寻找技术鲨鱼
一些老的技术一直被沿用，这些是技术鲨鱼，而不是落后的技术恐龙。它们解决问题的能力非常强大，以至于在快速变化的技术世界中存活下来。不要瞧不起这些技术，没有很好的理由也不要替换掉这些技术。这些技术不花里胡哨，也不震撼人心，但是它们能帮你避免许多个彻夜不眠来完成任务。
15. 不要把谦逊当成无知
有许多工程师，你不问他，他就不会发表意见。永远不要以为没人当面diss你，就代表你做的足够好、没有改进空间了。有时候，我们不太想倾听那些最吵闹的人的意见。和你身边的人沟通，向他们请教问题、寻求反馈，你会庆幸你这样做了。
16. 软件工程师应该定期写作
软件工程师应该定期写博客、写日记、编写文档，总之需要做一些事，来锻炼写作沟通的技能。写作帮助你思考问题，帮助你跟团队的成员，以及未来的自己更好的沟通。优秀的写作沟通技能是软件工程师必备技能之一。
17. 让你的流程尽量精简
现在，每个工程师都想变得”敏捷”，”敏捷”指的是以小块的方式构建软件，并不断学习、持续迭代。如果有人试图将更多的东西塞到这个流程中，那么他们可能在推销敏捷开发以外的其他观点。我并不是说敏捷开发过程不需要问责和帮助。但是你有听过喜欢的科技公司或者大型开源项目中有人在吹嘘自己优秀的Scrum流程吗？在你真的需要更多之前，保持流程的精简。相信你的团队，他们会交付的。
18. 跟所有人一样，软件工程师也需要归属感
如果你让一个人和他的工作成果脱钩，那么他就不会认真对待工作。我觉得这是必然的，而这也是跨职能团队非常有效的主要原因，也是DevOps变得这么流行的原因。这不仅仅关乎任务交接和效率的高低，而且关乎负责从头到尾的整个过程，并且对交付成果负有直接的责任。让一群充满激情的人完全负责设计、构建和交付（软件或任何东西），惊人的事情就会出现。
19. 面试几乎无法判断一个人会不会成为出色的团队成员
面试最好用于尝试了解一个人是谁，以及他对某个专业领域的兴趣。想要在面试中判断一个人会不会成为出色的团队成员，几乎是徒劳。请相信我，一个人是不是聪明、是不是知识渊博，跟他会不会成为出色的成员没有任何关系。在面试中，没人会告诉你他这个人不可靠、他喜欢冒犯别人、他傲慢且自以为是、他从不按时参加会议。有些面试官声称通过一些迹象能判断出来：“如果第一次面试中途请假，那他们肯定不会再来了”，都是胡扯。如果你用这些迹象来猜测判断，那你可能失去优秀的候选人。
20. 持续努力构建更小的系统
有很多因素会推动着你，从一开始就构建更大的系统。比如无法确定预算如何分配、无法决定砍掉哪些功能、希望交付系统的“最佳版本”等。所有这些事情都会强烈地推动着你去构建更多的东西、更大的系统。你应该反对这件事。在构建系统的过程中，你还会学到更多东西，最终系统会迭代成一个比最初设计更好的系统。我很惊讶为什么很多人不认可这一点。
那么你呢？
所以，以上就是我20年的职业生涯概括出的20条思考。如果其中有什么让你感同身受，我愿意听听你的反馈。我也很愿意听到你在职业生涯中都有哪些思考，如果你想分享，请自由的在评论区留言吧~