本文已取得原作者Justin Etheredge的翻译授权 原文链接
写在前面
你即将读的这篇文章会给你许多主张，向长辈学习关于取得成功是很有协助的，但咱们常常会忘记很重要的一点，便是简直一切的主张都是有其特定场景和上下文的，但当人们给出主张的时分却很少带着上下文。
一家一向以来以“收费低”而取得成功，并经营了二十年的公司或许会给出的主张是“你只需求多收些钱！”。
“你需求把一切运用都构建成微服务”这个主张或许来自于一个靠快速构建的单体运用取得不计其数客户，在开端遇到规划问题时转向微服务的团队。
假如不理解上下文，这些主张就毫无意义，乃至是有害的。假如这些人早些时分遵从了自己的主张，那结果怎么也很难讲。咱们很或许处在自己阅历的高峰，但却在用现在的视角看待他人的问题。
首先我想介绍一下我的主张从哪儿来，我作业生涯的前半段是一名软件工程师，为各种小型企业和初创企业作业，然后进入咨询行业，并在一些非常大的企业作业。后来自己创建了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.一直尽力构建一个更小的体系
有许多的力气将推动你预先建立更大的体系。预算分配，无法决议哪些功用应该被减少，希望交给体系的“最佳版本”。一切这些作业会迫使咱们过度建设。你应该与之抗争。在构建体系的进程中，你会学到许多东西，终究迭代得到的体系将比你开始规划的体系要好得多。令人惊讶的是，这很难压服大多数人。
