编写代码之外的思考
我想引用一个非常聪明的人的一段话：你的目标是通过代码解决问题。
如果你对需要构建/维护的系统有深刻的了解，则可以做出纯技术之外的决策。这个功能有必要吗？它能解决什么问题？我们可以用其他方式解决这个问题吗？我们想要解决这个问题吗？
这种思路有时被称为业务环境，但是如果你想做好自己的工作，则不仅应该了解环境，还应该能够塑造和影响这个环境。并非只有在组织中担任高管的人才能影响产品。至少，你需要了解。
这不仅关系到你编写的代码，即使你不会触及的代码也同样重要。高级开发人员能够考虑到代码之外的事情，从更广泛的角度看待他们的产品，并考虑他们的下一行代码是否会有助于实现团队的目标。
举个例子——你可以花费整个Sprint，根据规格利用react-helicopter来实现两个不同版本的界面，然后启用A/B测试验证。这是一个了不起的方法。
但其实，你可以考虑（例如）公司80%的销售额都来自20%的用户。为什么不给这些用户发送电子邮件？询问他们的意见？或者也可以直接打电话给他们？
当然，这只是一个简单的例子，但它说明了一个问题：我们首先应该考虑的是问题，而不是代码。大多数问题可以都通过多种方式解决，高级工程师都应该思考编写代码之外的东西。
帮助他人
有一种感觉：你确切地知道功能的全部含义，你可以戴上耳机，在悠扬的音乐声中心无旁骛地写一天代码。这种感觉简直无与伦比，是不是？
确实如此，然而如果你周围的人需要帮助，那么你就不能置身事外了。高级开发理应指导其他经验不足的开发人员。我个人见过很多经验丰富的开发人员，他们显然忘记了茫然不知所措的样子。
有一点很重要，我们需要记住，那就是并非每个人都适合进行一对一的面对面指导，这没关系。你可以通过代码审查，编写良好的README文档，以及为文档和体系结构决策（理想情况下，这些文档应有据可查）做出贡献等方式，来帮助别人达成目标。简而言之，你应该成为“+10% BUFF的工程师”。
高级工程师经验丰富，但是将这些经验据为己用绝对不公平。我个人认为高级工程师这个职位最重要的一项职责是促进知识共享的文化。
写博客、演讲资料、文档或在Slack上粘贴链接，这些方式统统可以。看到同一家公司里的两个团队重复解决同一个问题是一件可悲的事情，而高级开发需要确保这种情况不会发生。
怎样才能晋升到高级开发的职位？
首先你需要提升自己。
严肃地说，晋升到高级开发职位的最佳方法是胜任高级开发的工作。
开拓代码的视野，洞悉代码与整个系统的关系。积极地观察，挖掘优化的机会。针对你的应用进行性能审核（无需他人提醒），并努力将你的主页的性能提高10%。积极地帮助他人（他们会心存感激）。积极地推进组织的知识共享文化，积极地为这些计划做贡献。走出舒适区，积极地为其他项目和任务贡献自己的力量。
最后，祝大家好运！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69948718/viewspace-2666896/ ，如需转载，请注明出处，否则将追究法律责任。
