软件工程师未来三年的成长计划（从20年软件工程师生涯学会的20件事）
软件工程师未来三年的成长计划（从20年软件工程师生涯学会的20件事）代码之外，也有解决方案不要忘记，我们不只是程序员，不是会编写代码，我们也是人，可以有别的解决方案。手里拿个锤子，看什么都像是钉子。人们通常在他们擅长的事情上“犯错”，这可能是职业病，天性，或者惯性思维在作祟吧。当我们面对问题时，特别是哪些非技术解决方案不那么明显的时候，总是习惯于使用代码解决问题。而事实上，最好的解决方案是不需要解决方案，而同样地，最好的代码是不需要代码。我们不必要重复地发明轮子，要习惯于在代码之外寻求解决方案，从根本上说，就是通过权衡，寻找那个最经济而有效的解决方案。建立用户思维，做正确的软件软件是给人用的，代码不也是吗？作为软件工程师，是否思考过代码的“用户”体验呢？优秀的工程师会考虑自己的代码、API、UI、协议等等，会被谁在什么情况下使用？为什么使用？如何使用？乃至对这些“用户”来说，哪些是至关重要的？这就是所谓的用户思维、产品思维和商业思维吧？通过共情，了解并牢记
引言本文基于一篇英文博客而创作，但并不是仅仅对原文的翻译，因为一直比较关注软件研发相关的思想实践，所以借着原文作者的列表发挥一下，也看看大家是否有同感和共鸣，文末也会给出原文地址，喜欢的可以看原文。
我仍然很无知在软件领域，无论你看向哪个方向，都有着广阔的知识视野，而且处于不断地蔓延中。这就是有着近乎相同长时间职业生涯的，而且角色看似相似的人，他们之间仍然有巨大知识差距的原因。“你不是从事IT行业的吗？为什么不会修电脑？”，“你居然不懂Rust？”，类似的话，可能会经常听到。所以，在这个行业，就需要保持谦虚，做个终身学习者，乐于向他人学习并教导他人。
在深度和广度上持续学习
最难的是做出正确的东西这虽然会被认为贬低我们的工作价值，但的确是事实，并成为普遍认知。我们可以做出让人赞叹的东西，但不得不承认，那不一定是正确的东西。我们一定都见过那张从需求到设计，到上线有巨大差异的图片，这张图片就深刻地揭示了这一点。软件研发的工作环境是复杂的，非理性的，我们必须同时成为软件工程师、沟通专家、心理学家和人类学家，具备相当的知识，接受专门的UX训练（这些当然可以团队合作），才能有机会做出正确的软件。
建立用户思维，做正确的软件
优秀的软件工程师要像设计师一样思考软件是给人用的，代码不也是吗？作为软件工程师，是否思考过代码的“用户”体验呢？优秀的工程师会考虑自己的代码、API、UI、协议等等，会被谁在什么情况下使用？为什么使用？如何使用？乃至对这些“用户”来说，哪些是至关重要的？这就是所谓的用户思维、产品思维和商业思维吧？通过共情，了解并牢记这些，也是做出正确软件的要求吧。
换位思考，多想想你的各种“用户”
最好的代码是没有代码，或者是不必维护的代码不要忘记，我们不只是程序员，不是会编写代码，我们也是人，可以有别的解决方案。手里拿个锤子，看什么都像是钉子。人们通常在他们擅长的事情上“犯错”，这可能是职业病，天性，或者惯性思维在作祟吧。当我们面对问题时，特别是哪些非技术解决方案不那么明显的时候，总是习惯于使用代码解决问题。而事实上，最好的解决方案是不需要解决方案，而同样地，最好的代码是不需要代码。我们不必要重复地发明轮子，要习惯于在代码之外寻求解决方案，从根本上说，就是通过权衡，寻找那个最经济而有效的解决方案。
代码之外，也有解决方案
软件只是达到目的的手段这基本和上一条表达的是同一个意思。软件只是手段，只是解决方案，而不是目的。我们要意识到我们的工作始终是在交付价值（用户价值、商业价值），而且要内化这一点。这样，我们看待问题的视角就会不同，就会建立更全面的视角，从而会发现更多的解决问题的方案，也可能发现那个最适合的“工具”，可能不是软件。
站在更高的视角看待问题，软件不是目的
有时必须停止磨刀，直接开始每个人工作习惯不同。有的人会单刀直入，直接开始编码。而有些人则喜欢先做研究分析，并陷入其中。经验告诉我们，走极端总是不好的。代码极具特殊性，让我们可以先从一个小而丑的实现开始，逐步迭代到更好的解决方案。而常常在开始动手后，很多问题就自然而然地冒出来了，就会对问题有更深的了解。所以，写代码，我们可以稍作规划，即刻开始，逐步迭代。
逐步迭代到更好
设计不能脱离技术长时间没有编写代码，将不了解整个代码生态系统，不知道哪些是可能的，哪些又是好用的，除了解决最简单的问题外，不能为所有问题给出最为合理的解决方案。所以，架构师也需要跟上开发生态，不写代码的架构师，不是好架构师，不了解技术的产品经理，不是好产品经理。
技术是核心要素
每个系统最终都会很糟糕，我们要做的就是克服它大家一定听过熵增原理吧，在没有外部能量让其有序的情况下，封闭系统会越来越趋向于混乱。“世界上只有两种语言：人们抱怨的语言和没有人使用的语言”。软件系统也是这样，侯门一入深似海，业务在发展，不会有一直“正确”的架构，永远有需要偿还的技术债务，永远不会有设计完美的界面，而测试速度也总是跟不上需要。但这不是我们让事情放任自流的借口，而是告诉我们，没有最好，只有更好，不要过度追求优雅和完美，而是通过努力持续改进，来建设一个“宜居”的系统，让团队成员在其中工作，并持续地交付价值。
努力做得更好
多问“为什么”我们知道，人和动物最本质的区别就是人会反省。所以，我们要用好这个与生俱来的能力，抓住任何机会，质疑那些“一直以来的做事方式”的假设和方法。你一定听过那个，切香肠要习惯性地切掉两端的那个故事吧，经过认真追究，原来是因为她的曾外婆时代的烤箱很小，不切掉两头，香肠就放不进去，所以一直谬传下来。做软件的我们也应该注意到了，当新成员加入团队的时候，总是会因为困惑，问很多为什么。这时，就给了我们一个很好的反思的机会。有没有值得重新思考的地方？会不会发现意义的新功能需求？如果没有答案，就把5Why分析法用起来，继续多问为什么，直到有所获。
抓住机会，质疑反省
把精力放在避免低效程序员（0.1x）上，而不是寻找高效程序员（10x）原作者认为10x程序员是个愚蠢的神话。一个产出10倍于普通人的程序员（1x），通常需要10倍的次数来修复他的代码。和0.1x的程序员进行比较，就会发现，10x程序员通常不测试他们的代码，不考虑边缘情况，不和相关人确认，等等。所以，我们应该着重去把0.1x的低效程序员排除到团队之外，而不是努力寻找10x程序员。
避免本末倒置
高级工程师往往思维固化高级工程师往往对自己的工具或如何构建软件习以为常，没有任何意见，这很可怕，又让人担心。我们处在一个不断变革的时代，需要体验更多新东西，需要探索其他语言、库和范例。很少有这种，向其他人学习他们的不同工具和方法，可以快速提升自己技能的方法了。宁愿有人给出强烈反对意见，也不愿让他们没有意见，这才是我们应有的生活态度。
避免因循守旧
人们并不真的想要创新人性是懒惰和保守的，习惯于待在温暖又安全的舒适区。这也就是人们常常谈论创新，但是要的只是获得表象上新奇的刺激，就像叶公好龙，只是说说而已。当你真的去创新，去改变人们做事的方式，立刻会招致多数人的反馈和排斥。如果了解变革曲线的话，就会从其中过山车一样的情绪曲线中体会到这一点。所以，变革和创新是艰难的，如果你相信正在做的事情，并且知道它真的会改善事情，那么请为此准备好做一场漫长战斗的准备。
为创新做好战斗准备
数据比代码很重要从数据中可以提取信息，从信息中可以获得知识，从知识中可以汲取智慧。我们生活在一个数据的时代，数据比以往任何时候都容易产生价值，从而变得更为重要。然而，系统中常常会各种原因产生脏数据，失去其完整性，导致将来处理时困难重重。所以，我们要认识到，数据的生命周期可能比代码更为长久，需要投入精力保持其整洁和有序，以利于我们从中受益。
重视数据的重要性
寻找技术“鲨鱼”鲨鱼是一种古老的鱼类，从已知的化石来看，它们比恐龙还早大约4亿年。恐龙已不复存在，鲨鱼却繁盛至今。所以，存在即“合理”，一些古老的技术，就像鲨鱼一样，在不断变化的技术世界中幸存了下来，它们可能不会很华丽，也不会令人兴奋，但它们可以长时间默默地正常工作，而不是一个又一个的不眠之夜。所以，只有在理由充分时，才去替换它们。
寻找技术“鲨鱼”
不要把谦卑误认为无知工程师都有自己的个性，也常常在工程师身上听到闷骚型这个词，这一定是有其背后的原因的。有很多工程师，除非被问到，否则他们不会轻易发表意见。无知的人更容易狂妄，而拥有丰富知识的人更了解自己的无知，会更加谦卑。所以，我们永远不要假设他们只是没有发表意见，就没有什么可补充的。有时，最吵闹的人是我们最不想听其说话的人。与身边的人多交流，主动去征求意见吧，一定会大有收获的。
主动交流，定有斩获
软件工程师应坚持写点什么著名的费曼学习法告诉我们，输出才是最好的学习（当然还有刻意练习）。软件工程师通过坚持定期写博客、日志、文档，可以保持书面沟通的技巧，可以促使思考问题，更加有效地和团队成员沟通，和未来的自己沟通。
在输出中学习
尽可能保持流程精益每个人都说他们做了敏捷，但几乎没有人是真正敏捷的。敏捷做得不好，往往会让人感觉更为混乱。所以，敏捷就纯粹的敏捷，不要掺杂其它的东西，不要为了敏捷而敏捷，要把握敏捷的精髓，要相信团队，团队会形成自己的最佳实践，会完成交付。
把握敏捷精髓，保持流程精益
和普通人一样，软件工程师需要有归属感如果你把某人从他们的工作成果中分离出来，他们就会不那么关心他们的工作。归属感、参与感和所有权很重要，在DevOps中，开发人员从头到尾拥有整个过程，直接负责交付看得见的价值，会让他们充满激情，任何惊人的事情都会发生。
注重参与感和团队归属感
不要试图通过面试挑选优秀的团队成员面试重点最好放在试图了解某人是谁，以及他们对特定专业领域的兴趣程度上，而不是试图弄清楚他是否会成为一个优秀的团队成员，那将是徒劳的。聪明和知识渊博，并不代表一定会是伟大的团队成员。没有人会在面试中告诉你，他会不可靠、辱骂、浮夸，或者永远不会准时参加会议。有人会说他们会从其中发现相关的“信号”，但实属胡说八道。如果利用这些“信号”，只会猜测并拒绝那些好的候选人。
面试重在了解
始终努力构建更小的系统有很多力量会诱惑或推动你预先构建更大的系统。这包括总是期望构建最佳状态的系统，而很难舍弃某些功能。事实上，从一开始就想设计和建造一个大而美的系统，通常会是复杂和失败的前奏，而通过迭代，可以逐步创建一个比最初设计更好的系统。但这种做法通常很难被多数人认可和接受。
从小开始
结语正如作者所说，这些经验有其上下文，也就是局限性，个别可能有失偏颇，不会适用于所有的情况，有些我们无法理解或认同，但是，有思想的交流就已经很好了，不是吗？
原文地址无法贴出，大家可搜索20 Things I’ve Learned in my 20 Years as a Software Engineer（作者：Justin Etheredge）进一步查看。
