作者丨Joy
译者丨核子可乐
企划丨赵钰莹
本文作者Joy接触过的几乎每一家软件公司都设有技术晋升与管理晋升两条职业公路,这意味着假如只走技术方向,技术人员也完全可以在不出任管理职务的前提下达到相同的高阶职级。但与此同时高级软件工程师考试,Joy所出席的几乎所有职业讲演或讨论小组都参杂着管理人员。如今,Joy总算明白从宏观层面来看,管理者究竟须要做哪些、管理的晋升通道又是怎样一回事。
无论是在公司内还是公司外,管理晋升通道中的高层都有着更高的著名度。技术高管也是这么,但对于负责技术的中层管理人士,好多人可能就有点摸不清原委了。
在这儿,我先给你们交个实底:在第一次接触软件行业时,假如你们问我10到15年以后想要做哪些工作,我首先想到的答案无疑是软件构架师。我对管理岗位没有太通州趣,但是我晓得构架师是技术公路上最资深的人群。但是,那时的我并不清楚构架师究竟须要做哪些,当时想到这个答案的诱因无非是野心与想证明自己的渴求。但刚好,我后来的发展公路或多或少遵循了当年的愿望,只是现今的我更清楚兼任中级技术管理者意味着哪些。
工程技术角色汇总
我如今是一名中级软件工程师,但这到底是干嘛的?其实具体的头衔与职能界定取决于具体的企业,但依据我们借助微软搜索结果进行的建模,整个行业内的定位思路大体相像。我最初是一名软件工程师(简称SWE),而后是中级软件工程师(SrSWE),经历了短暂的管理适应周期后,我最终晋升为中级管理人员。在此之上,还有首席工程师与研究员等职位,不过据我所知我们公司似乎还没有真正的研究员。另外让人有点犯迷糊的是,前两个阶段虽然基本是统一的;这意味着即便工作内容相同,在高层管理者看来,不同职工之间一直存在着巨大的差别。
依据与中级软件工程师的交流,对于较低职级,企业其实希望职工尽可能诠释自己的技能与才气。我们希望每个晋升为中级软件工程师的职工都能在一切领域(比如技术技能、领导力、文化与价值观等)中充分诠释自己的水平,在各项指标中起码达到标准要求,同时把握中级工程师所必需的一切技能。
值得指出的是,各个职级的工作内容略有不同。正由于这般,即使我们希望职工才能从中级软件工程师开始一步步成长上来,但技术人员也完全可以在接出来的职业生涯中出任同样的职务。假如有人就是喜欢做中级软件工程师,而对主管工程师没有兴趣,那我们也充分尊重这样的选择。
在我看来,随着时间的推移高级软件工程师考试,对角色变化最简单的描述方法就是观察其在影响力层面的变化。具体来讲,我们可以通过如下几个角度来考量:要么就是才能形成更广泛的影响,要么就是才能形成更深远的影响。具体来说,我们可以影响好多团队,或则对单一团队形成重大影响。我们也可以用另一种形式来理解:以编撰代码为例,我们可以编撰一部份超级重要或则超级复杂的代码,因而影响某一特定业务区域的运作方法;也可以指导别人进行编码最佳实践,或则对多项设计提出意见或则影响其决策方法,因而形成更广泛的影响。
说到这儿,我的论述可能还是有点具象和艰深。下边继续深入谈谈中级软件工程师究竟是哪些的。
中级软件工程师的工作内容
我并不是说这是中级软件工程师的惟一日常,我只是开诚布公地告诉你们,我是怎样工作以及怎样看待这份工作的。我的工作内容主要分为两大类别:首先是实际战术,即日常任务内容;第二类不太显著,但同样十分重要,即我是怎样审视以及处理这种任务的。
我花了点时间思索自己每晚须要处理的具体事务,并把它们整理成一份图表。我肯定遗漏了一些内容,但是具体工作每周还会出现显著波动(因而这只是一份简略的图表,仅供你们参考)。
我意识到,自己只花了大概一半的工作时间直接为Scrum团队完成任务。其中包括所有团队大会,我认为这进一步突出了流程精简的重要意义。我承认,这部份工作跟我早年间的工作内容十分相像。即使如今采取的具体方式有所变化,但在性质上并没有多大区别。具体包括编撰设计文档、编写代码、进行代码审查以及测试所有代码等内容。
接出来的部份同样抢占了相当比列的工作时间(大概20%),这就是技术咨询(图表当中的红色部份)。其中包括为各种设计方案——包括我自己的团队与其他团队提供咨询建议,回答技术问题以及在API标准委员会任职等。其中一部份与我的直接团队相关,但大多数是面向企业内的各个团队。有些问题还跟我个人有关,由于我其实早已成为中级工程师,但当年入职时做的好多项目还在发挥作用,所以有时须要回答一些相关问题。随着所参与的项目数目不断降低,这方面工作内容也在持续下降。另外,尽管仍然在回答问题,但我对于问题的审视形式与回答,或则说我提出的设计建议,也在随着时间推移而发生变化。
至于剩下的时间,基本上就是花在指导别人、建立更大的项目规划、技术品牌以及其他杂活头上。在指导当中,又分为即将指导与非即将指导。非即将指导通常就是一对一当面传授心得,即将指导自然是在诸多朋友面前通过演示文稿的方式讲解项目知识了,但是可能涉及一场甚至是多场会议。其实即将指导看似有用,但我自己的觉得是它在我的指导内容当中只占很低的比列。相反,在大多数情况下,最好的方法常常是只立足一到两个问题围绕同一主题进行讲解。在非即将指导方面,我更倾向于称其为同伴指导或则互相指导。这并不是单纯的导师/中学生那个关系,而是我会把我自己的问题与思路分享给朋友,她们也同样向我分享。我们都能为对方提供看法与看法,并从其他人的不同观点当中获益。
小型项目规划包括与其他中级工程师及总监合作,为我的团队或则所在部门设定技术方向。其中还可能包括改善工程中的多样性与宽容性等。基本上,这种都是囊括多个团队的常年战略项目。随着时间的推移,我先后参与了诸多不同的小型项目(包括我之前提到的这些)。有时侯同学们会约请我加入讨论,但通常来说我都能早一步发觉问题并主动组织讨论。
接出来是技术品牌问题,我的主要工作就是帮助企业改善品牌形象。就个人而言,这主要涉及撰写博客文章,外加接受采访或则帮助别人编辑文章内容。其中一些属于宣传性信息,但也有一些更注重于学习与分享,借以引导我们的工程师对于部门中正在研究的个别课题形成兴趣。
最后,我提及的杂项包含不太好归类的其他工作内容。其中涵盖了各类各样的事务,包括接受专访、参加技术讨论或则出席公司内的黑客马拉松活动等。这种事情同样重要,但在时间占比上相对比较有限。
假如我在刚才入职的时侯能够读到这样一份清单,这么我的职业规划应当会愈加明晰。虽然尽管这与中级工程师没啥关系,但以当时自己的能力而言,我早已完全可以胜任其中的大部份内容。不过我也承认,真正变化的并不完全是技能,而是我在处理这种任务时采取的形式以及在任务当中的关注重点。这些态度层面的变化,在重要性方面甚至不逊于工作技能。虽然从时间占比来看,具体事务只占工作时长的一半左右。
原文链接:
点个在看少个bug