写在前面
你即将读的这篇文章会给你很多建议，向前辈学习对于获得成功是很有帮助的，但我们经常会忘记很重要的一点，就是几乎所有的建议都是有其特定场景和上下文的，但当人们给出建议的时候却很少带着上下文。
一家一直以来以“收费低”而获得成功，并经营了二十年的公司可能会给出的建议是“你只需要多收些钱！”。
“你需要把所有应用都构建成微服务”这个建议可能来自于一个靠快速构建的单体应用获得成千上万客户，在开始遇到规模问题时转向微服务的团队。
如果不理解上下文，这些建议就毫无意义，甚至是有害的。如果这些人早些时候听从了自己的建议，那结果如何也很难讲。我们很可能处在自己经历的顶峰，但却在用现在的视角看待别人的问题。
首先我想介绍一下我的建议从哪儿来，我职业生涯的前半段是一名软件工程师，为各种小型企业和初创企业工作，然后进入咨询行业，并在一些非常大的企业工作。后来自己创建了Simple Thread，团队从2人发展到25人。10年前，我们主要与中小型企业合作，现在与大大小小不同的企业合作。
我的建议来自于这些人：
几乎总是在小而精干的团队中，必须用很少的资源做很多事情。
重视可工作软件而不是特定的工具。
在维护多个系统的同时，一直有新的项目要启动。
把工程师的生产力看得比大多数其他因素都重要。
我过去20年的经历塑造了我对软件的看法，并引导我形成了一些信念，我试图将这些信念精简并整理成一个列表，希望你会觉得它对你有所帮助。
我的列表
1.“我依然知道的不够多”
“你怎么会不知道BGP是什么?“ “你从来没听说过Rust吗?”。我们很多人经常听到过类似的话。很多人喜欢软件开发的一个重要的原因是我们是终身学习者，软件开发中，无论你从哪个方向看，都有广阔的知识前景在各个方向发展，并且每天都在扩大。这意味着与其他职业中花费几十年的人相比，你即使已经花费了数十年，但可能仍然有巨大的知识断层，有很多新知识需要学习，你可能因为担心不能胜任而陷入焦虑。你越早意识到这一点，你就能越早摆脱这种时常的焦虑，从而放平心态，乐于向别人学习以及教授他人。
2.软件最难的部分是构建正确的东西
我知道这已经是陈词滥调了，但是还是有很多软件工程师不相信这一点，因为他们认为这会贬低他们所做的工作。我个人认为这是无稽之谈。相反，它强调了我们工作环境的复杂性和非理性，这更突出了我们所面临的挑战。你可能可以设计出全世界技术上最牛的东西，但却没有人愿意使用它，这种事经常发生。设计软件主要是一种倾听活动，我们经常不得不一半是软件工程师，一半是心理学家，一半是人类学家。在这个设计过程中投资自己，无论是通过专门的用户体验团队的成员还是通过简单的自学，都会带来巨大的回报。因为构建错误软件的成本可不仅仅是浪费了工程师的时间。
3.最好的软件工程师会像设计师一样思考
优秀的软件工程师会深入考虑他们代码的用户体验。他们可能不会用这些术语来考虑它，而是考虑它是外部API、编程式API、用户界面、协议还是任何其他接口;优秀的工程师会考虑谁会使用它，为什么会使用它，如何使用它，以及对这些用户来说什么是重要的。牢记用户的需求才是好的用户体验的核心。
4.最好的代码是没有代码，或者不需要维护的代码
任何职业的人解决问题的过程中都会在自己擅长的方面犯错误，这是人的本性。大多数软件工程师在编写代码免不了会犯错误，尤其是当还没有可行的非技术性解决方案时。工程团队总是倾向于在已经有很多轮子的时候重新发明轮子。有很多原因让你自己重新做一个轮子，但一定要警惕有毒的“Not invented here”综合症，不能闭门造车，妄自尊大，尽量复用和寻找非技术性解决方案。
5.软件是达到目的的一种手段
任何软件工程师的主要工作都是交付价值。很少有软件开发人员能理解这一点，更少人能内化它。真正的内在化会带来一种不同的解决问题的方式，以及一种不同的看待工具的方式。如果你真的相信软件是屈从于结果的，你就会准备好真正找到“适合这项工作的工具”，而这个工具可能根本不是软件。
6.有时候你不得不停止磨刀，开始切东西
有些人倾向于一头扎进问题中，然后开始编写代码解决问题。有些人却倾向于花大量时间研究和调查，但却让自己陷进问题中。在这种情况下，给自己设定一个最后期限，然后开始探索解决方案。当你开始解决这个问题的时候，你会很快学到更多的东西，这将引导你迭代形成一个更好的解决方案。
7.如果你不能很好地把握全局的可能性，你就无法设计出一个好的系统
这是我在每天的工作中不断努力的事情。与开发者生态保持同步是一项巨大的工作，但了解开发者生态中的可能性却是至关重要的。如果你不了解在一个给定的生态系统中什么是可能的，什么是可用的，那么你就不可能设计出一个合理的解决方案来解决所有的问题，除非是最简单的问题。总而言之，要警惕那些很长时间没有编写任何代码的系统设计者。
8.每个系统最终都很糟糕，克服它吧
比雅尼·斯特劳斯特鲁普（Bjarne Stroustrup）有一句话是这样说的: “世界上只有两种语言，一种是人们抱怨的语言，另一种是没人用的语言。”。这也可以扩展到大型系统。不存在“正确”的架构，你永远无法偿还所有的技术债务，你永远无法设计出完美的界面，你的测试总是太慢。这不是个能让事情变得更好的借口，而是一种让你看问题的方式。少担心优雅和完美；相反，要努力持续改进，创建一个你的团队喜欢并可持续提供价值的环境。
9.没人去问“为什么”
抓住任何机会去质疑那些“一直以来都是这样做的”假设和方法。有新队员加入？那就注意他们在哪里感到困惑，他们问了什么问题。有一个没有意义的新功能需求？确保你理解了目标，以及是什么驱动了这种功能的需求。如果你得不到一个明确的答案，继续问为什么，直到你明白。
10.我们应该更加关注如何避免0.1x程序员，而不是寻找10x程序员
10倍的程序员其实是一个愚蠢说法。认为一个人可以在一天内完成另一个有能力、勤奋、同样有经验的程序员可以在两周内完成的任务是愚蠢的。我见过程序员抛出10倍的代码量，然后你必须用10倍的时间来修正它。一个人成为10倍程序员的唯一方法就是将他与0.1倍程序员进行比较。有些人浪费时间，不寻求反馈，不测试他们的代码，不考虑边界情况等等。我们更应该关心的是让0.1x程序员远离我们的团队，而不是找到神秘的10x程序员。
11.高级工程师和初级工程师之间最大的区别之一就是他们对事情应该如何发展形成了自己的观点
没有什么比高级工程师对他们的工具或如何构建软件一无所知更让我担心的了。我宁愿有人给我一些强烈的反对观点，也不愿他们没有任何观点。如果你正在使用你的工具，并且你并不喜欢或讨厌它们，那么你就需要体验更多。您需要探索其他语言、库和范式。没有什么方法比积极地寻找别人如何用不同的工具和技术来完成任务能更快地提升你的技能了。
12.人们不是真的想要创新
人们经常谈论创新，但他们通常寻找的是廉价的胜利和新奇的东西。如果你真的在创新，改变人们做事的方式，那么大部分的反馈都是负面的。如果你相信你正在做的事情，并且知道它真的会改善事情，那么就做好长期斗争的准备。
13.数据是系统中最重要的部分
我见过许多对数据完整性要求很高的系统。在这样的系统中，任何发生在关键路径之外的事情都会创建部分数据或脏数据。将来处理这些数据可能会成为一场噩梦。请记住，您的数据可能比代码库存在的时间更长。把精力花在保持它的有序和清洁上，从长远来看它会得到很好的回报。
14.寻找技术”鲨鱼“
许多留下来的老技术是”鲨鱼“，而不是”恐龙“。他们能够很好地解决问题，并在技术不断快速变化的今天生存了下来。只有在有一个很好的理由的情况下，再去替换它们。这些工具不会华而不实，也不会令人兴奋，但是它们可以完成工作，避免很多不必要的不眠之夜。
15.不要把谦卑误认为无知
有很多软件工程师在没有被提问的时候，是不怎么发表意见的。永远不要以为别人没有他们的观点摆在你面前，你就觉得他们没有什么观点。有时候最吵的人恰恰是我们最不想听的人。与你周围的人交谈，寻求他们的反馈和建议。你会有意外收获。
16.软件工程师应该定期写作
软件工程师应该定期写博客，写日志，写文档，去做任何保持书面沟通技能的事情。写作可以帮助你思考问题，并帮助你与团队和未来的自己更有效地沟通。良好的书面沟通能力是任何软件工程师都需要掌握的最重要的技能之一。
17.保持流程尽可能精简
如今，每个人都想变得敏捷，“敏捷”就是把事情分成小块，学习，然后迭代。如果有人试图把更多的东西塞进去，那他很可能是在卖东西。想想你有多少次听到来自你最喜欢的技术公司或大型开源项目的人在吹嘘他们的Scrum流程有多棒?在你知道你需要更多的东西之前，请依靠流程。相信你的团队，他们会完成任务。
18.软件工程师，像所有人一样，需要有归属感
如果你把某人和他的工作成果分开，他就不会那么在乎他的工作。我认为这几乎是同义反复。归属感是跨职能团队工作得如此出色的主要原因，也是DevOps变得如此流行的原因。这并不全是关于交接和低效的问题，而是关于从开始到结束去参与和享受整个过程，并直接负责交付价值。让一群充满激情的人完全拥有设计、构建和交付一个软件(或者其他任何东西)的所有权，奇妙的事情就会发生。
19.面试对于判断一个团队成员是否优秀几乎毫无价值
面试最好是试着了解对方是谁，以及他们对某一特定专业领域有多大兴趣。试图弄清楚一个团队成员会有多好是徒劳的努力。相信我，一个人有多聪明或多有知识也不能很好地表明他们将是一个优秀的团队成员。没有人会在面试中告诉你，他们会不可靠，会骂人，会夸夸其谈，或者从不准时出席会议。人们可能会说他们在这些事情上有“信号”……“如果他们在第一次面试时就问请假，那么他们就永远不会在那里了!” 但这些都是胡扯。如果你使用这样的信号，你只是在猜测，并将优秀的候选人拒之门外。
20.始终努力构建一个更小的系统
有很多的力量将推动你预先建立更大的系统。预算分配，无法决定哪些功能应该被削减，希望交付系统的“最佳版本”。所有这些事情会迫使我们过度建设。你应该与之抗争。在构建系统的过程中，你会学到很多东西，最终迭代得到的系统将比你最初设计的系统要好得多。令人惊讶的是，这很难说服大多数人。
作者：沉默的小河马
链接：https://juejin.cn/post/7195472887586193467
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
