初级工程师关心编写软件。他们重视代码质量，采用最佳实践，投入大量时间学习新技术，最终目标是创建优雅、高性能、可维护的软件。
高级工程师关心构建系统。对他们来说，创建软件只是一个步骤。他们首先质疑是否需要构建软件，询问它会解决什么问题，以及为什么解决这些问题很重要，然后询问谁将使用该软件和使用规模，并且考虑软件将在哪里运行以及如何监控，还决定如何衡量软件是否真正解决了它应该解决的问题。
以下为全文译文：
初级工程师关心的是编写软件。他们重视代码质量，采用最佳实践，尝试采用前沿技术。他们投入大量时间学习新技术。对他们来说，最终目标是创建优雅的、高性能的、可维护的软件。
高级工程师关心构建系统。对他们来说，创建软件只是其中一个步骤。首先，他们质疑是否首先需要构建软件。他们会问这能解决什么问题，为什么解决这些问题很重要。他们询问谁将使用该软件以及使用规模。他们考虑软件将在哪里运行，以及他们将如何监视软件是否正常工作。他们还决定如何衡量软件是否实际上解决了它应该解决的问题。
构建系统比构建软件难得多。甚至可能会不舒服。作为一名工程师，呆在自己的洞穴里专注于完善这段美丽的代码是非常诱人的。人们很容易认为确定需求是产品经理的工作，而部署软件应该由运营团队负责。然而，通过参与构建系统的这些方面，您可以带来很多价值。你是最了解你的软件的人，也是最了解如何运行它、如何监视它、扩展它有多容易等等的人。更重要的是，你的分析能力和解决问题的能力使你对产品需求的洞察力非常有价值。
技术专长当然是非常重要的。优雅的、高性能的、可维护的软件更容易运行、更少中断、更容易扩展和推理。然而，它可能会解决一个错误的业务问题。或者可能客户不喜欢它，因为您甚至不知道性能问题，因为您没有监视它。
让我们更深入地看一下构建系统的一部分活动的列表(并非详尽无遗) :
- 定义需求-与产品经理一起工作，了解他们想要解决什么问题; 也许你会有一些想法，如何用更少的努力来解决它？
- 定义 NFR-与 PM 讨论非功能性需求-系统应该处理多少用户，对性能、吞吐量和延迟的需求是什么？是否有任何安全性或遵从性考虑因素？我们需要审计吗？需要的可用性是什么？
- 计划迭代——与您的团队一起提出一个实现计划; 确保您定义了小的、可拆卸的里程碑，以便您可以尽快开始交付价值; 在里程碑上与 PM 达成一致。
- 确定依赖关系——确保您确定了团队之外的所有依赖关系，并与您的 EM 或团队直接合作，以获得一些预计到达时间。相应地调整你的里程碑。
- 测试——取决于你的公司如何运作，与你的团队或 QE 团队一起决定你的测试策略。同意推出所需的质量阈值(例如没有未解决的主要错误或测试覆盖率超过 X%)。
- 部署-与您的团队一起决定如何部署系统。您是否需要一些新的基础设施，或者可以重用现有的基础设施？如果你需要很多的话，需要多少钱？
- 可观测性——决定如何监控系统的健康状况，并建立解决生产问题的流程(例如团队待命)。使用第三方解决方案(如 Sumo Logic)来设置监视器和仪表板。
- 展开沟通——一旦你与你的团队和项目经理就展开日期达成一致，确保所有的利益相关者都意识到这一点。检查是否需要更改文档。
- 衡量成功——确定能够告诉你项目是否成功的度量标准。有人在用新系统吗？用户是否设法完成他们的任务？为此，您可以利用您的可观察性套件。
我遇到过许多工程师，他们坚信提升职业生涯的唯一途径就是投资于他们的技术技能。虽然这一点很重要，但对你的公司来说，唯一重要的事情是你对业务的影响有多大。将重点从软件转移到系统将使您处于一个更好的位置来增加它。
留言