【翻译】什么造就了“高级工程师”？编写程序 VS 构建系统

作者：Miłosz Piechocki

初级工程师关心什么？

他们关心如何编写程序。他们最看重的是软件质量，采用最佳实践，并尝试采用最前沿的技术。他们投入了大量时间去学习新技术。对他们来说，最终目标是编写出优雅、高性能、可维护的软件。

高级工程师关心什么？

他们关心如何构建系统。对他们来说，创建软件只是一系列流程中的一步。

1. 第一步，他们质疑这个软件是否值得创建，这是首要的。他们会问，这个软件解决了什么问题，为何这些问题的解决很重要，谁会用这个软件以及用到什么程度。
2. 软件应该运行在哪里，以及如何监控它以确保它正确地运行。
3. 他们还会决定，如何衡量软件真的是在按照设计的要求去解决问题。

构建系统比建造软件的难度高多了，甚至到了一个不舒服的程度。作为一个工程师，躲在自己的“小洞穴”中专心打磨那些小代码，是非常诱人的一件事。一般来说，我们倾向于认为，业务的决定是产品经理的工作，代码的部署是运维团队的事情。然而，如果你参与到系统构建的这些环节中来，将会带来巨大的价值。因为你是最了解这个软件，以及应该如何运行、监控、扩展这个软件的人。还有，你的分析能力、解决问题的技巧，让你的关于产品需求的洞察观点十分有价值。

技术上的专业知识当然非常重要。编写出优雅、高性能、可维护的软件，更容易运行，崩溃的频率更少，更容易扩张且需要更容易理解。但是，软件有可能解决了错误的业务问题；或者客户因为性能缺陷并不喜欢它，而你甚至因为没有没有监控到软件而不知道这个事情。

系统构建的活动

一起来深入地看看，这个系统构建的活动步骤列表（并不详尽）。

1. 制定需求。跟产品经理一起理清，要解决客户的什么问题，或许你会有一些如何用最少精力去完成任务的方法？
2. 制定非功能需求。告诉产品经理一些非功能需求——系统能容纳多少用户，需要的性能、吞吐量、延迟是什么？有没有安全和合法性上的顾虑？我们要不要审核？规定的可用度是什么？
3. 计划迭代。和你的团队一起，制定一份实行计划，确保你制定了细小的、可行的进度管理。然后你就能尽快地递交成果，跟产品经理确认里程碑了。
4. 制定外部援助。确保你搞清楚了所有的外部援助，跟你的项目经理或者团队沟通，为他们争取一些排期，并根据此来调整里程碑。
5. 测试。取决于你的公司运行方式，来决定你与团队或者质量团队的测试策略。协商好发布时候需要的质量阈值。（比如不能有未解决的重大问题，或者测试覆盖率要超过 X%）
6. 可观测性。决定好你要怎么监控系统的健康状况，和设置解决产品问题的流程（比如团队值班）。用第三方方案（比如 SumoLogic）来设置监测器和仪表盘来实现这个需求吧。
7. 发布沟通。一旦你与团队和产品经理协商好了发布日期，请确保所有利益相关人都知道这个事情。检查一下是不是有必要更新某些文档。

总结

我遇到过很多工程师，他们都坚信职位晋升的唯一方法，就是不断投入精力到专业技能上。当然这很重要，但唯一关系到你的公司的事情是，你能对业务营收产生多大的影响。把注意力从软件，转移到系统上来吧。改善系统比改善软件，更能让你上升到好的职位。