从一个普通开发人员到高级开发人员，他们之间有什么差距呢?只需要通过努力提升自己专业知识就能弥补这些差距嘛?阅读这篇文章，你就知道，高级开发人员比你高的不仅仅有技术，更多的是对成长晋升的思考。

职位的定义往往非常棘手。毕竟，确立某人为初级/普通/高级开发的过程就像是设法将他们掌握的所有技术都归结到一个“标签”中。

“您认为，高级开发人员和普通开发人员有什么区别?”

这个问题没有正确答案，而且我并不觉得每个人的答案都一样。就个人而言，我认为这个问题能引发有关开发人员广泛职责的讨论。此外，我真诚地希望了解他人的观点——我们的工作是编写代码?还是编写测试?还是交付产品?指导别人?写文档?我们是人类吗?还是说我们是舞者?

更努力、更好、更快、更强

当我刚步入开发的职业生涯时，我记得公司的高级工程师给我留下了难以置信的印象。他们拥有不可思议的力量，无论你提出何种问题，他们都能够解决。

是的，作为高级开发人员，你应该能够解决与专业领域相关的各种问题。然而，高级开发不是机器。

而且他们也不应该是机器，高级开发并不意味着：“这个人每小时可以编写30个redux action。”我敢肯定，在有些公司里，如果你能成为一个更好、更快、零bug的开发人员，那么就能获得晋升。但是老实说，高级开发的意义不仅限于此。这不是一个“是什么”的问题，而是一个“怎样”的问题，更重要的是“为什么”的问题。

很多书通篇都在描述关于技术决策的制订。这是一个极其复杂的领域，需要考虑很多因素。最好的方法是提出多种做法，同时回避一些做法。而不是千篇一律地说：

“过去20年中，我一直在做这份工作，所以我会坚持做下去，因为除此之外我什么都不懂，而且坦白说我有点害怕学习新东西。”所有这些都非常重要，但问题在于：我认为高级开发人员必然会对他们的组织产生影响。这意味着：他们的工作不仅仅是将JIRA票转换成代码。

编写代码之外的思考

我想引用一个非常聪明的人的一段话：你的目标是通过代码解决问题。

如果你对需要构建/维护的系统有深刻的了解，则可以做出纯技术之外的决策。这个功能有必要吗?它能解决什么问题?我们可以用其他方式解决这个问题吗?我们想要解决这个问题吗?

这种思路有时被称为业务环境，但是如果你想做好自己的工作，则不仅应该了解环境，还应该能够塑造和影响这个环境。并非只有在组织中担任高管的人才能影响产品。至少，你需要了解。

这不仅关系到你编写的代码，即使你不会触及的代码也同样重要。高级开发人员能够考虑到代码之外的事情，从更广泛的角度看待他们的产品，并考虑他们的下一行代码是否会有助于实现团队的目标。

举个例子——你可以花费整个Sprint，根据规格利用react-helicopter来实现两个不同版本的界面，然后启用A/B测试验证。这是一个了不起的方法。

但其实，你可以考虑(例如)公司80%的销售额都来自20%的用户。为什么不给这些用户发送电子邮件?询问他们的意见?或者也可以直接打电话给他们?

当然，这只是一个简单的例子，但它说明了一个问题：我们首先应该考虑的是问题，而不是代码。大多数问题可以都通过多种方式解决，高级工程师都应该思考编写代码之外的东西。

帮助他人

有一种感觉：你确切地知道功能的全部含义，你可以戴上耳机，在悠扬的音乐声中心无旁骛地写一天代码。这种感觉简直无与伦比，是不是?

确实如此，然而如果你周围的人需要帮助，那么你就不能置身事外了。高级开发理应指导其他经验不足的开发人员。我个人见过很多经验丰富的开发人员，他们显然忘记了茫然不知所措的样子。

有一点很重要，我们需要记住，那就是并非每个人都适合进行一对一的面对面指导，这没关系。你可以通过代码审查，编写良好的README文档，以及为文档和体系结构决策(理想情况下，这些文档应有据可查)做出贡献等方式，来帮助别人达成目标。简而言之，你应该成为“+10% BUFF的工程师”。

高级工程师经验丰富，但是将这些经验据为己用绝对不公平。我个人认为高级工程师这个职位最重要的一项职责是促进知识共享的文化。

写博客、演讲资料、文档或在Slack上粘贴链接，这些方式统统可以。看到同一家公司里的两个团队重复解决同一个问题是一件可悲的事情，而高级开发需要确保这种情况不会发生。

版权声明：转载文章来自公开网络，版权归作者本人所有，推送文章除非无法确认，我们都会注明作者和来源。如果出处有误或侵犯到原作者权益，请与我们联系删除或授权事宜。