重要，请先阅读
您即将阅读一篇充满许多建议的博客文章。从前人的经验中学习对于成功至关重要，但我们经常忽视一个重要的警告。几乎所有的建议都是有情境的，但很少带有任何背景信息。
“你只需要涨价！”这家经营了20年的公司说道，他们花了很多年“收费过低”以吸引客户并取得成功。
“你需要将一切都构建成微服务！”这家公司曾构建了一个快速的单体系统，吸引了成千上万的客户，然后在遇到扩展问题时转向了微服务。
没有理解背景信息，这些建议就毫无意义，甚至可能是有害的。如果这些人早期遵循了自己的建议，他们自己很可能会受到影响。要摆脱这个陷阱是很难的。我们可能是经验的结晶，但我们将它们视为现在的镜头。
所以，为了让您对我的建议有一些背景了解，我在职业的前半段是一名软件工程师，为各种小型企业和初创公司工作，然后我进入了咨询行业，在一些非常大的企业工作。然后我创办了Simple Thread，我们的团队从2人发展到25人。10年前，我们主要与中小型企业合作，现在我们与大大小小的企业都有合作。
我的建议来自一个…
- 几乎总是在小而精干的团队中工作，在资源有限的情况下需要做很多事情。
- 将工作软件价值看得比具体工具更重要。
- 不断开始新项目，但也必须维护多个系统。
- 将工程师的生产力看得比大多数其他因素更重要。
在过去的20年中，我的经验塑造了我对软件的看法，并使我形成了一些信念，我试图将它们归纳为一个有价值的可管理的清单。
看看这个清单
1. 我仍然几乎一无所知
“你怎么可能不知道BGP是什么？”“你从未听说过Rust吗？”我们中的大多数人可能经常听到这些说法。之所以很多人喜欢软件，是因为我们是终身学习者，在软件领域，无论你往哪个方向看，都有广阔的知识领域，不断扩展。这意味着你可以在职业生涯中度过几十年，仍然与那些也在类似角色中度过几十年的人相比，有巨大的知识差距。越早意识到这一点，你就越早能够摆脱冒充综合症，而是从学习和教导他人中获得愉悦。
2. 软件最难的部分是构建正确的东西
我知道这在现在已经成为陈词滥调，但大多数软件工程师不相信这一点是因为他们认为这会贬低他们的工作。个人认为这是荒谬的。相反，它突显了我们必须在复杂和非理性的环境中工作的复杂性，这加剧了我们的挑战。你可以设计出世界上最令人印象深刻的技术，然后却没有人想要使用它。这种情况经常发生。设计软件主要是一个倾听的活动，我们常常必须既是软件工程师，又是心理学家，还是人类学家的一部分。投资于这个设计过程，无论是通过专门的用户体验团队成员还是通过简单地自己学习，都将带来巨大的回报。因为你怎么能真正计算出构建错误软件的成本？它远不止于丧失的工程时间。
3. 最优秀的软件工程师像设计师一样思考
优秀的软件工程师深刻地思考他们代码的用户体验。他们可能不会用这些术语来思考，但无论是外部API、程序化API、用户界面、协议还是任何其他接口；优秀的工程师都会考虑谁会使用它，为什么会使用它，如何使用它以及对这些用户来说什么很重要。将用户的需求放在心中实际上是良好用户体验的核心。
4. 最好的代码是没有代码，或者是你不必维护的代码
我只想说“程序员总是要写代码的”。你问任何一个专业人士如何解决一个问题，他们都会倾向于使用他们擅长的方法。这只是人类的本性。大多数软件工程师总是会倾向于写代码，尤其是在非技术性的解决方案不明显的情况下。对于你不必维护的代码也是一样。工程团队往往会希望重新发明轮子，而已经有许多轮子存在。这是一个平衡的过程，有许多原因可以自行发展，但要警惕有毒的“非本公司研发”综合症。
5. 软件是达到目的的手段
任何软件工程师的主要工作是提供价值。很少有软件开发人员能理解这一点，甚至更少能内化它。真正内化这一点会导致以不同的方式解决问题，以及以不同的方式看待你的工具。如果你真的相信软件是结果的从属品，你将准备好真正找到“最适合工作的工具”，这可能根本不是软件。
6. 有时候你必须停止磨刀，开始开工
有些人倾向于跳入问题并直接开始编写代码。其他人则倾向于想要研究和研究，陷入分析瘫痪。在这些情况下，为自己设定一个截止日期，然后开始探索解决方案。随着你开始解决问题，你会很快学到更多，这将引导你进入更好的解决方案。
7. 如果你不了解可能发生的事情，就无法设计一个好的系统
这是我很多时候都在与之奋斗的事情，因为我的责任使我越来越远离了日常的软件工程。跟上开发者生态系统是一项巨大的工作，但了解在给定生态系统中可能发生的事情至关重要。如果您不了解在给定生态系统中可能存在的东西，那么除了最简单的问题外，您会发现很难设计出合理的解决方案。总之，要警惕那些长时间没有写过任何代码的人设计系统。
8. 每个系统最终都不完美，请接受这一点
比雅恩·斯特劳斯特鲁普（Bjarne Stroustrup）有一句名言：“只有两种语言：人们抱怨的语言和没人使用的语言”。这也可以扩展到大型系统。没有“正确”的架构，您永远无法还清所有技术债务，您永远不会设计出完美的接口，您的测试永远会太慢。这并不是借口永远不去改进，而是一种给您提供透视的方式。不要过于担心优雅和完美；相反，努力不断改进，创建一个令团队愉快并可持续提供价值的可居住的系统。
9. 从不问“为什么”的人太少
任何时候都要质疑“一直以来都这样做”的假设和方法的机会。有新的团队成员要加入吗？注意他们在哪里感到困惑，以及他们提出了什么问题。有一个看起来不合理的新功能请求吗？确保您理解了目标以及驱动对此功能的渴望的因素。如果你没有得到明确的答案，就一直问为什么，直到你明白为止。
10. 我们应该更加关注避免0.1倍程序员，而不是寻找10倍程序员
10倍程序员是一个愚蠢的神话。认为一个人可以在1天内完成另一位能力出众、勤奋工作、经验相似的程序员在2周内完成的工作是荒谬的。我见过那些编写了10倍数量代码的程序员，然后你不得不把它修复10倍的次数。只有当与0.1倍程序员进行比较时，某人才能成为10倍程序员。某人浪费时间，不寻求反馈，不测试他们的代码，不考虑边缘情况等等。我们应该更加担心让0.1倍程序员远离我们的团队，而不是寻找神秘的10倍程序员。
11. 资深工程师和初级工程师之间最大的区别之一是他们对事情应该如何进行形成了观点
没有什么比一个资深工程师对工具或如何构建软件的方法没有意见更令我担忧了。我宁愿有人给我提出我强烈反对的意见，也不愿意他们根本没有意见。如果你正在使用你的工具，而且你不喜欢或讨厌它们的多种方式，你需要体验更多。你需要探索其他语言、库和范例。与你使用不同工具和技术完成任务的其他人如何，是提高你技能的几种方法之一。
12. 人们并不真的想要创新
人们经常谈论创新，但他们通常寻求的是廉价的胜利和新颖的东西。如果你真正创新，改变人们必须做事情的方式，那么请预计会收到大部分负面反馈。如果你相信你正在做的事情，并且知道它会真正改善情况，那么请为长期战斗做好准备。
13. 您的数据是系统中最重要的部分
我见过很多系统，其中希望是数据完整性的主要机制。在这样的系统中，任何偏离正常路径的事情都会导致部分或脏数据。以后处理这些数据可能会变成一场噩梦。只要记住，您的数据很可能会比您的代码库长寿。花费精力使其有序和清洁，在长期内会有很好的回报。
14. 寻找技术上的“鲨鱼”
那些经久不衰的旧技术不是恐龙，而是鲨鱼。它们解决问题的能力如此出色，以至于它们在技术世界中不断发生的快速变化中幸存下来。不要押注这些技术，除非你有非常充分的理由来进行替换。这些工具可能不会很炫目，也不会很令人兴奋，但在不需要很多彻夜未眠的情况下，它们能够完成工作。
15. 不要将谦虚误认为无知
有很多软件工程师不会在没有被问到的情况下表达意见。永远不要假设仅因为某人没有把他们的意见推到你面前，他们没有什么可以添加的。有时，最吵闹的人可能是我们最不愿意倾听的人。与你周围的人交流，寻求他们的反馈和建议。你会感激自己这样做的。
16. 软件工程师应该经常写作
软件工程师应该定期撰写博客、写日记、编写文档，总之要做任何需要他们保持书面交流技能的事情。写作有助于你思考问题，也有助于你与团队和未来的自己更有效地沟通这些问题。良好的书面沟通是任何软件工程师掌握的最重要的技能之一。
17. 使您的流程尽可能精简
如今，每个人都想要灵活性，但“灵活”是指以小块方式构建事物，学习，然后迭代。如果有人试图把更多的东西塞进去，那么他们可能在卖东西。这并不是说人们不需要责任或帮助以这种方式工作，但是你有多少次听说过来自你最喜欢的技术公司或大型开源项目的人吹嘘他们的Scrum流程有多好？在你知道需要更多之前，保持流程的精益。相信你的团队，他们会交付。
18. 软件工程师，像所有人一样，需要感到拥有
如果你把某人与他们的工作产出分开，他们会对他们的工作不太关心。我几乎把这看作是一种自明的道理。这是跨职能团队效果如此好、DevOps如此受欢迎的主要原因。这与交接和低效率无关，而是关于从头到尾拥有整个过程，并对交付价值负有直接责任。让一组充满激情的人完全拥有设计、构建和交付软件（或任何其他东西），令人惊叹的事情会发生。
19. 面试几乎没有价值，无法告诉我们一个人是否是一个好的团队成员
面试更好地用于尝试了解某人是谁，以及他们对某个专业领域的兴趣有多大。试图查明某人是否是一个优秀的团队成员是徒劳无益的努力。而且相信我，某人的聪明程度或知识水平也不能说明他们会成为一个优秀的团队成员。没有人会在面试中告诉你，他们会不可靠、虐待、自大或从不按时参加会议。人们可能会声称他们对这些事情有“信号”……“如果他们在第一次面试中询问请假时间，那么他们永远不会出现！”但这些都是胡说八道。如果你正在使用这些信号，你只是在猜测并拒绝了好的候选人。
20. 始终努力构建更小的系统
有许多力量会推动你一开始就构建更大的系统。预算分配、无法决定应该削减哪些功能、提供“最佳版本”的系统的愿望。所有这些都会强烈地推动我们过度建设。你应该抵制这一点。在构建系统的过程中，您会学到很多东西，最终会进一步改进一个比您一开始设计的系统更好的系统。这对大多数人来说都是一个难以置信的难题。
您的故事是什么？
所以，在这里有20年的软件经验浓缩成了20条简洁的智慧。如果有什么让您有共鸣的地方，我会很高兴听到。如果您在职业生涯中有一些智慧的经验，想要分享的话，我也很愿意听听。请随意在评论区留言。
