编译 | 云昭
作者 | Roberto Gambuzzi
审校 | Ethan
什么是“首席软件工程师”？许多公司给出的定义都有所不同。圈内一些人将之称作“员工工程师”（ Staff Engineers）；而在其他一些公司，他们是众人拥戴的团队领导者，还有一些接触不多的朋友，将“主管”（Lead）和“首席”（Principal）混为一谈。那么，首席软件工程师，究竟是怎样的存在？有哪些核心的职责呢？
Roberto Gambuzzi，目前一直在担任首席工程师的职务，同时也是Magento认证开发者（Magento，一套专业开源的PHP电子商务系统）。自1997年开始，Roberto就成为了一名程序员，在长达25年的时间里，他曾在AWS、谷歌等几家巨头公司内屡次担任首席软件工程师的角色。
不得不说，Roberto是稳稳的第一代程序员了，在各科技行业给出的定义非常不一致的情况下，他是如何看待这一角色的呢？Roberto结合自己的实际经历归纳出了6个用以定义该岗位的关键概念。
个人贡献者（IC）：编码圈的扛把子
很多人认为，职位一旦挂上“首席”就意味着这个角色需要参加各种大大小小的会议。但首席软件工程师并不是这样子的。实际上，需要他们参加的会议并不多。首席工程师也是工程师，编码依旧是“天职”。他们依然需要与代码打交道：进行系统设计，修复bug，优化数据库等等。在代码世界里，他们要探索其他程序员害怕去的地方。
他们要处理各种疑难杂症：进行繁琐的外部依赖版本升级，关注测试覆盖率，解决外部库和内部代码的安全问题；他们审查其他开发人员的代码，并且通常会将他们挨个惹恼一遍：在代码的关键部分要求更多的日志、更多的指标、更好的错误处理、更好的算法。最气人的是，他们知道什么时候可以不那么严格，去降低这些限制。并非所有软件功能都具有同等的重要性，Roberto在这里举了一个例子。在电子商务中，必须始终有效的功能包括：查看产品、添加到购物车、支付购物车。其他的诸如：建议、历史订单、发货费预览、营销电子邮件等等，相较而言就没那么重要了。因此，这些模块的程序，一般都会出错。当然，但无论如何，这些Bug都必须尽快修复。
不盲从：为对的任务选对的技术
他们懂得很多技术，可以为真正值得展开的任务选择正确的技术。“首席”当然需要“博学”，这一点毋庸置疑，也只有做到技术上的“博学”才会让这个角色有“固执己见”的底气。他们必须知道语言、数据存储和其他粘合技术之间的差异。另外，首席工程师绝不能盲目追求炒作，必须深入了解背后的特性与原理，不能浮于表面。例如，Postgresql数据库仍然是解决大多数问题的最佳方式，而将数据保存在S3上并使用AWS Athena可以解决其他问题；Java在许多场景下都能有效的解决问题，Go往往擅长的是解决其他问题，同样，Rust很快，但构建时间很痛苦；Python可以用于请求密集型API吗？是的，如果任务不是CPU密集型的。如果想成为首席软件工程师，随时更新自己是常态，不要追随炒作。切忌把当下流行语挂嘴边，却不知道自己到底在说什么。
轻轻推：更新公司的技术栈
首席软件工程师必须不断突破公司现有技术菜单的界限，但要轻轻推。当然，一家公司必须始终对变化持开放态度。因而首席工程师被受任之际，往往会给予更新公司技术栈的重任。
在推广新技术时，一定要尊重之前遗留的历史。一家公司选择技术背后有很多原因，要推动变化，就需要公司内部的“政治资本”——
- 对于那些通过内部晋升而来的人来说，这种资本已经存在，因为他们已经在公司内花费了大量时间在相关方建立关系。
- 而对于直接雇佣的情况，你就需要一些时间来影响“现状”，因此，首席工程师也需要良好的沟通技巧。
这里之所以说是“沟通技巧”而不是“软技能”，是因为在Roberto看来，“软技能”这个词的明面含义会让人觉得：这些技能很弱，但事实并非如此。对于软件开发人员来说，他们可能更擅长的是与机器交互，而不是跟人“斗智斗勇”。同时，首席工程师需要提出新的想法。整个过程可能会有抵制，这是关乎人性、意料之中的事情。要推广新技术，就要学会用数字和指标来说话。如果你能证明从Java迁移到Go，会让AWS的账单成本降低为十分之一，那老板当然乐于接纳Go的方案。
影响力：跨团队辐射业务
“高级（Senior）”和“首席（Principal）”有没有明显的分界线？答案很清楚，那就是影响范围的大小。首席软件工程师必须跨越多个团队。他们从不同的角度了解公司的业务。达到这个水平需要时间。
首席工程师可以被分配到一个团队，但也可以在团队之间跳转，每次都从事不同的项目。参与各种项目，更多的是个人/公司的决定。在大公司（如亚马逊AWS），首席工程师的影响范围可以是至少50名工程师，较小型的公司可能会少一些。那么，一家小公司需要首席工程师吗？对于一家小公司来说，首席技术官和首席工程师通常是同一个人。如果首席技术官不够熟练，则需要首席工程师，但解决问题的范围会更小一些。
教习官：非技术人指导也讲究
大多数时候，指导开发人员都很有趣。他们想要学习，共同点是帮助人与人之间的信息传递。但并非所有参与软件开发的人都是软件工程师。产品经理、用户体验设计师等等也在那里。首席工程师必须用更简单的术语解释，不要深入到技术实现中，解释公司使用的技术的局限性，可以做什么来改进，以及技术决策会给公司带来多大的成本。不要使用流行语或首字母缩略词。比如，PM有时会要求无限量地保留用户数据，以在网站上获得更快的用户体验，但所有这一切都有成本。首席工程师必须能够解释所有这些，并帮助寻找权衡。
高产高效当先
首席工程师不是经理。他们无须进行冗长的汇报。让其他程序员更happy的工作，也并非这一角色的职责。首席工程师的作用在于令开发人员高效、高产出地工作，而不是像经理那样使用组织技术去改善公司内部的开发体验。一条需要三天才能运行的管道，首席工程师将努力使其在30分钟内运行。可能这一结果，会让每个人都更开心。但首席工程师不会处理其他类型的问题，这些问题通常是经理的问题，如绩效、晋升、个人问题…
晋升首席软件工程师是好事吗
升职总是好的，每个人都喜欢更高的薪酬和Title。选择了首席工程师，就意味着：虽然你将会有更多的会议和更少的时间来编写代码，但是你的代码会产生更大的影响。如果你决定挑战这个角色，需要考虑一下问题：首先，在这个级别获得晋升或聘用是不同的。回到“影响力”的话题，作为新员工加入这一级别的公司具有挑战性，因为同事、经理和整个公司都希望看到这种影响力。但作为一名新加入的成员，你需要适应公司的标准和技术。其次，称谓的变化无需太过计较。在目前的公司中被称为“高级”（Senior）的人可以成为其他一些公司的“负责人”（Principal），反过来也是这样。所以要注意这一点。工资可以很好地反映工作水平。如果一家公司给你提供一个首席软件工程师的职位，其基本工资与你目前的高级职位相同……那么这家公司可能是一家小公司。你必须只为这个角色接受这份工作吗？答案是否定的。
在Roberto看来，工作是为了金钱或经验，而不是为了头衔。如果在另一家公司以同样的薪水成为首席软件工程师可以教会你一些东西，那就去做吧。仅仅追求“首席”的头衔而去，那就得不偿失了。最后，切记：“权力越大，责任越大”。
总结
“首席”是一个自带光环的字眼，技术圈也不例外。从“高级”、“资深”到“主管”、“经理”、“负责人”、“CTO”等等，开发人员的职业发展终归绕不开这些，P岗、M岗的选择这里不再展开，但如果你选择在技术岗位上纵深发展，那么首席软件工程师，又何尝不是一种非常契合的岗位！代码世界的魅力需要有人带头推动，既不像CTO那样更侧重业务的视野去考虑全局，又不会深深陷入某个项目团队重复造轮子，技术原地踏步，这样对“首席工程师”的描述可能会有些失真，但对于热衷于推动新技术的开发者而言，将变得非常有意义！
参考资料：https://blog.hulacorn.com/2022/06/02/what-is-a-principal-engineer/
