为什么我不是高级工程师

doMore 467 2022-11-28

参考文章:https://codewithstyle.info/software-vs-systems/

思考

工作以来一直在观察,职称为高级的开发工程师具有什么样的特点,为什么我不是高级?

前言

工作中碰见很多的高级开发,他们对一些新的技术不了解,写出的代码也并不是那么优秀,不会用更高级的语法特性。但是他们在一些处理系统方面有自己的理解。比如,他们会更加注重监控系统,会花费一定的时间去观察服务的运行,会在意 qps,服务器的配置,接口的安全性,信息是否会泄露等等一系列。

正文

纵观所遇到的初级工程师,普遍会关心软件的编写,重视代码的质量,采用最先进的技术,也会投入大量的时间区学习新的技术,以创建优雅的、可执行的、可维护的软件为最终目标。

而高级工程师普遍更关心建立系统。对于他们而言,创建软件只是其中的一个步骤。首先,他们质疑是否需要首先建立这个软件。他们会问它能解决什么问题,为什么解决这些问题很重要。他们询问谁将会使用这个软件,在什么规模上使用。他们考虑软件将在哪里运行,以及他们将如何监测它是否正常工作。他们还决定如何衡量该软件是否真正解决了它应该解决的问题。

建立系统要比建立软件难的多。作为一个工程师,待在一个地方,专注的打磨一段代码,写的优雅漂亮是非常有成就感。理所应当的认为确定需求是产品经理的工作,部署软件由运营团队负责。然而,恰恰是参与构建系统这些方面,工程师能够带来更大的价值。因为工程师才是最了解这个软件的人,知道怎样运行它,怎样监控它,怎样更容易地扩展等等。更重要的是,工程师的分析能力和解决问题的能力使工程师对产品需求的洞察力非常有价值。

不能说技术是不重要的,它能创建优雅的,可执行的,可维护的软件,使软件更容易运行,更少发生故障,更容易扩展等。然而,客户却可能不会喜欢这个软件,即使软件能够帮助解决很多问题。不喜欢的原因有很多种,比如:性能问题。而这些没有合适的监控手段,工程师一无所知。

询问过一些高级工程师,也看过一些网络上的文章,个人总结了一些建立系统所需要的清单(并非详尽无遗):

  • 定义需求 - 与产品经理一起工作,了解他们想要解决什么问题;这会使你有一些想法,如何使用更低的代价来解决问题?
  • 定义实际的系统指标 - 与你的 产品经理 讨论非功能需求 如: 系统应该处理多少用户,对性能、吞吐量、延迟有什么要求?是否有任何安全或合规方面的考虑?我们需要审计吗?希望的可用性是什么?
  • 迭代规划 - 与团队合作,提出一个实施计划;确保定义小的、可演示的里程碑,这样就可以尽快开始交付价值;与项目经理就里程碑达成一致。
  • 确定依赖性 - 确定团队以外的所有依赖性,与直接与团队沟通,相应地调整你的进度以及规划
  • 测试 - 这取决于公司如何运作,与团队或与QE团队一起决定测试策略。就推广所需的质量门槛达成一致(例如,没有未解决的主要错误或测试覆盖率超过X%)
  • 部署 - 与团队合作,决定该系统如何部署。是否需要一些新的基础设施,或者可以重新使用现有的基础设施?如果需要大量的,成本会是多少?
  • 可观察性 -- 决定如何监测系统的健康状况,并建立解决生产问题的流程(例如,团队待命)。使用第三方解决方案(如Sumo Logic)为该目的设置监控器和仪表盘。
  • 推广沟通 - 一旦的团队和项目管理人员就推广日期达成一致,确保所有利益相关者都知道这个日期。检查是否需要修改任何文件。
  • 衡量成功 - 决定项目是否成功的指标。是否有人在使用这个新系统?用户是否设法完成了他们的任务?可以利用 可观察性 套件来达到这个目的。

我见过不少的工程师,他们确信他们的职业生涯的唯一途径是投资他们的技术。这虽然很重要,但对公司来说,唯一重要的是你对业务的影响是多大。将重点从构建软件到构建系统,应该可以让你处于一个更好的位置。