约翰·奥尔斯波（John Olspau）的这篇很棒的文章标题为“成为首席工程师” 。 大约四年前，当我刚转行到现在的工作时，我第一次阅读它，它的确影响了我这一职业领域的想法。

现在重新阅读后，那里似乎真的很有趣，移情和帮助团队是上级工作的重要组成部分。 当然是正确的！

但是现在我看到，我认识的大多数或所有领先工程师除了对他们的个人编程工作外，还对其他员工提供了重要帮助。 现在，在我看来，我和我的同事所面临的问题不是什么？ 需要与人交谈吗？ 令人难以置信的”，还有另一个问题：“如何在您个人的输入/编程与所有这些领导工作之间取得平衡？ 我应该从事多少工作？” 因此，我不想谈论Olspau文章（我完全同意）中的君主的迹象 ，而是要谈论我们正在做的工作 。

这篇文章是关于什么的

“首席工程师的工作”是一个很大的话题，但是这里只是一小篇文章，因此您应该牢记：

• 关于首席工程师的工作仅有一个可能的描述。 有很多工作方法，但这不应该是教条。
• 我主要只在一家公司工作，所以我的经验和观点显然很有限。
• 显然，有许多级别的“高级”。 它与Mozilla层次结构中的P3 / P4级别（高级工程师/职员工程师）有关，也许更接近“职员”级别。

职责是什么

在我看来，这些东西更多地是首席工程师的工作，而不是经理的工作（尽管经理肯定会做一些上述事情，特别是创建新项目并将项目与业务优先级联系起来）。

几乎所有这些工作本质上都是技术性的 ：帮助某人应付一个复杂的项目显然是人类的互动，但是我们将共同努力的问题通常是技术性的！ （“也许，如果我们简化设计，我们可以更快地应对！”）。

• 编写代码 （显然）。
• 进行代码审查 （显然）。
• 编写和审查设计文档 。 与其他评论一样，第三方外观可能会有助于改进设计。
• 帮助被困的同事 。 有时人们会陷入一个项目，为他们提供帮助很重要！ 我在考虑的不是“跳伞，将神奇的知识传给人们”，而是“共同理解问题，看看两个大脑是否能比一个更快地应对” ：）。 这也意味着一起工作，而不是解决另一个人的问题。
• 保持同事高尚 。 对于不同的人，“级别”具有不同的含义（对我的团队来说，这意味着产品的可靠性/安全性/便利性）。 如果某人做出我不喜欢的决定，则意味着我知道他不知道的东西，或者他知道我不知道的东西！ 因此，您无需说：“嘿，您做错了，您需要执行X，”但是最好只给他们提供他们没有的其他信息，这样通常就可以解决问题。 常常发现我缺少一些东西，实际上他们的解决方案很合理！ 在过去，我有时会看到领先的工程师试图通过大声重复他们的意见来保持质量标准，因为他们认为他们的意见是正确的。 我个人认为这种方法没有用。
• 创建新项目 。 软件开发团队不是零和的地方！ 我认识的最好的工程师不会把最有趣的工作留给自己，他们会创建新的有趣/重要的项目，并为其他人创造一个进行这项工作的空间。 例如，我团队中的某人开始重写我们的部署系统。 事实证明，该项目非常成功，现在整个团队都在研究易于实现的新功能！
• 计划项目的工作 。 这是关于为您正在从事的项目写下/报告一份路线图，并确保人们了解该计划。
• 提前报告项目风险 。 认识到什么时候进展不顺利，通知其他工程师/经理并决定要做什么是非常重要的。
• 报告成功！
• 做有益于团队/公司的第三方项目 。 我看到许多前辈有时会做一些小而重要的项目（例如，创建开发工具/帮助制定政策），最终帮助许多人做得更好。
• 注意项目与业务优先级之间的关系。
• 决定何时停止该项目 。 事实证明，当您需要停止/不开始进行某些工作时，很难理解。 :)

我首先将“编写代码”放在首位，因为实际上此任务很容易在优先级列表中滑落。 :)

列表中没有“进行估算/预测”项目。 我在这里还不是很好，但是我认为有一天值得花更多的时间在上面。

列表似乎很大。 看来，如果您做所有这些事情，那么它们将吸收您的所有智力资源。 我认为一般来说，将某个部分隔离并做出决定是有道理的：“现在，我将专注于X，Y和Z，如果我尝试制作B和C，我的大脑会爆炸”。

什么不是职责

这有点复杂。 我并不是说您不能彻底处理此类问题。 我认识的大多数领先工程师都花了大量时间思考这些问题，并为此付出了一些努力。

但是在我看来，划定界限是很有用的，因为有些人对团队和公司负有高度责任感-他们随时准备承担一切，结果他们将负担过多的工作，将无法做出技术贡献，这实际上是他们的责任。主营业务。 因此，确定某些界限有助于确定当局势动荡时寻求帮助的合理问题。 您的实际界限取决于您/您的团队。 :)

以下大多数是管理工作。 免责声明：经理所做的工作远远超过此处列出的内容（例如，“创建新项目”），在某些公司中，上述某些内容实际上可能是首席工程师的工作（例如，冲刺管理）。

• 为了确保每个员工都能根据自己的功绩获得奖励。
• 确保工作分配合理。
• 确保人们在一起工作良好。
• 确保团队凝聚力。
• 与每位员工私下交谈。
• 培训新经理，帮助他们理解对他们的期望（尽管我认为一流的程序员通常真的会参加这样的活动？）。
• 管理第三方项目（在我的工作中，这是领导该项目的任何工程师的工作）。
• 成为产品经理。
• 主管冲刺管理冲刺/确定每个工作的阶段/举行每周会议。

明确设置边界很有用

最近，当我与经理讨论职责时，我遇到了一个有趣的情况-我们意识到我们对职责的看法截然不同！ 我们澄清了这种情况，现在一切都井井有条，但让我意识到，达成期望非常重要。 :)

当我开始担任工程师时，工作非常简单-我编写了代码，试图提出有意义的项目，并且一切都很完美。 经理总是对我的工作有个清晰的主意，没有什么太复杂的。 现在情况已经改变了！ 因此，现在我相信我必须确定以下工作：

• 我可以/长期适合我。
• 我想做/通常很有趣并且符合我的个人目标。
• 对团队/组织有价值。

确切的措辞因人而异（并非每个人都有相同的兴趣和长处，例如，我不太擅长代码审查！）。 我认为，出于这个原因，讨论这个话题并达成期望就显得尤为重要。

不要为无法/不想做的工作而安顿下来

我认为，放弃我无法做的工作或从长远来看不会带来快乐的工作非常重要！ 即使您不太喜欢它，似乎也很想做很多工作（“哦，这对团队有好处！”，“好吧， 有人应该做！”）。 当然，有时我仅仅因为必须完成任务而承担任务，但是我认为对于团队的健康而言，员工做他们通常喜欢做的事情以及长远来看可以做的事情确实很重要。

因此，我将承担一些仅需完成的小任务，但重要的是不要同时说：“哦，当然，我将把大部分时间都花在我做得不好和不喜欢的事情上，没有问题” :)。 如果“某人”需要这样做，也许就意味着我们需要雇用/培训新人来填补这一空白。 :)

我还有很多东西要学！

尽管我已经开始理解“首席工程师”是什么（在我的职业生涯中已经有7年了），但是我仍然觉得我仍然需要学习更多有关这一方面的知识，我很想听听其他人如何定义界限你的工作！