Twitter Thread – 关于传统行业软件工程师的职业路径。

从工作的第一天开始,作为一个技术人员,我就从来都不写技术博客。我的博客永远只有我的生活,我的照片,我读的书,我走的路,我的喜怒哀乐,但不会有我的工作。

软件工程师其实是很容易入行的万精油职业,因为软件的存在首先是为了某一个行业的实体经济,解决实际的问题。随着你的工程师技能的增长,随着你行业的知识增长,每一个工程师都会面对接下来的技能点点哪边的问题:

点到行业里,点到管理技能上,点到技术深度上;这可能是最普遍存在的三个方向。

这三个方向本身,是分支或者术业专攻的关系,普通人在一条线上一路点下去,基本可以养活自己;能在两条线上都双修且修得深,则大多能表现出显著的搞定问题的能力,容易获得更多的机会更有挑战的岗位;能全栈修满的……我没见过,真没见过。

值得一提的是,这三条线都是需要专业技能,需要方法论指导,需要经验和归纳来不断演进的技术工种,本身并无高低之分。

我想根据这十来年的见识,试着思考一下他们之间的关系,并不一定错,但一定不全对,仅仅是我自己的记录而已。


先说技术工种吧。

杭州市2020年人均年工资132188,也就是如果没有年终奖,一年就拿12个月月薪,每个月是11016。在我看来,所有高于这个薪资的人都没有资格喊穷,因为在人生是否公平的问题上,你已经在中位数之上了。理论上,你目前的收入高于这个数越多,按正态分布,你的收入分位就更会显著上升。

上面这个计算是底层逻辑,我始终认为,只有在人均收入以下的时候,讨论付出的辛苦和回报是否匹配才有意义,因为不匹配意味着不公平。

在这条线以上,你的劳动力会被企业,行业,发展阶段,甚至资本随时定价,这个定价模型里,你的技能深度很多时候占比并不显著。

过去两年,面试了可能上百人。程序员市场的混乱是显而易见的。你会发现大量上一份工作拿高薪的水货,也会发现大量从薪资角度来说被低估,但HR并不愿意提供匹配薪资的很扎实的人。劳动力被定价的因素真的很多,谈谈我自己对软件工程师定价的理解吧。

程序员的基础是代码,编程能力。这个能力的顶层,是框架,语法,靠代码量和经验来积累,没有捷径;底层是抽象思维,数学,算法,靠天赋,专项学习,刷题来积累,没有捷径。这部分能力是通用的,可以帮助一个程序员去任何一个行业的软件开发岗位工作,是入门以后必经的路径。

这部分能力值,在互联网行业获得的定价会更高,传统行业会低一些。坦率地说,我并不认为这是由纯粹的行业技术含量决定的,更底层的原因是互联网资本驱动。

一个A轮融资的互联网公司,提供月薪30K给一个初级程序员。这只代表了这家企业目前的需求能够提供如此的定价而已,合理吗?我不知道。

研发技能点继续点下去,你会变成一个高级一点的程序员,你会承担项目里更重要的攻坚职责。技术架构,工程化,你会需要去学习比应用系统更底层的环境,数据中心,操作系统,网络协议,存储,一个都少不了。把程序在IDE写出来,和把程序工程化,在企业环境里跑起来,是两个完全不同的故事。

这件事很有意思的点在于,每一个大企业都有自己的解决方案,通过封装,通过标准化,通过框架让这些复杂的环境,基础设施,底层协议对业务层代码不可见,让公司的业务发展可以通过增加初级程序员而不是大量定价更高的高级程序员或者架构师来支撑。

全栈到哪里都是加分项,因为边际知识能极大的帮你搞定工作中的阻碍。你会发现,都是开发都会写代码,但有的人工作中很少遇到阻断,但有的人则表现出代码之外这也搞不定,那也不了解。全栈永远加分,但一来没有兴趣支撑,很少有人愿意往全面的方向去学习,二来很少有大厂直接招聘「全栈」。

全栈很贵,全栈很少。大企业的治理目标,一定是减少对专精人才的依赖,并不是付不起钱,而是承担不了公司核心运行逻辑依赖在个体自然人上的风险——这是个悖论呀。

另外一个方向,则是纯粹的技术深度。

无论程序语言,算法,数据库,中间件都有各自的学问,深度的理解,底层的改造重构都能够帮助企业解决各种技术难题,甚至突破当前的基础设施技术瓶颈。

这样的大牛会更像科学家,他们是行业技术发展的基础科学的奠基人。头部企业自然需要头部的专家,他们的定价完全非市场化,因为市场……并不那么需要科学家,只有科学才需要。

大部分的商业企业,对技术难点的攻坚,更愿意选择咨询公司,技术服务等方式让技术服务提供商来兜底(以及背锅),比自己养大牛容易多了,这个悖论的来由,和上面那个如出一辙。


总算说到行业了。

如果你的工程师经历逐渐超过5年以上,那么你一定在至少一个行业有了比较深的接触。比如医疗,物流,金融市场,零售银行,支付等。即使是产品软件而非企业软件,你的产品也是为了解决客户或用户的实际问题,对应的也存在一个依托的行业。比如建筑,制图,信息安全,项目管理等等。

非常粗糙的来描述,企业顶层设计首先是价值流,然后是业务能力,业务流程数据领域,然后是才是信息化系统和他们的基础设施。这才是为什么一个企业需要工程师们写代码来造系统。

虽然在软件研发的分工里,有产品或需求分析师帮你翻译业务需求,但如果程序员不懂业务,一定会有这些坑等在后面:

你可能无法准确的对数据建模,业务发展后系统经常要底层改造数据割接;你的系统关键设计灵活度差,无法有效响应业务开展后发生的变化(当然,你可以骂业务甲方傻逼需求老改);你系统的非功能需求可能和企业行业要求相差甚远(性能,安全,合规设计),总有人要背锅承担额外成本。

理论上同样的功能有无数种系统实现,但系统设计的时候你需要考虑业务复杂度,业务数据量,甚至你需要预测未来业务发展后,可能需要修改的系统功能。这些都能让未来维护系统,承接项目的时候游刃有余,团队生活质量提高,同时变成业务部门可以信赖的科技支柱。

先不谈领域架构师,企业架构规划这些进一步专精的岗位;最纯粹的对程序员来说,这些代码以外的知识,决定了你的代码和实际业务之间的距离。只要你在一个企业不是打算两年就走,那么一定是行业和领域内的业务视角决定了你的发展上限。

同时,行业差异是会带来非功能需求的不同的。不同行业,对风险的管理策略不一样,面对不同的法律法规的监管。这些不同,终究会体现在系统设计,企业管理,合规流程等种种方面。

作为银行业的从业者,基本上招聘5年以上的Lead,行业背景几乎是一个必要条件。因为缺乏金融监管下科技工作经历的程序员,无论基本技术如何扎实,都会需要后面有很大的培训成本。而更资深的工程师(10年+),90%的岗位都是需要他来解决企业,行业里的具体问题的,没有行业知识基本无法对口。就像之前说的,行业和市场不那么需要科学家,只有纯粹的科学才需要。


总算说到管理了。

谈管理的时候,首先我们需要认可两个底层逻辑。

管理5个人和管理500个人,不是同一件事。

企业中,每个层级应该承担每个层级的责任。

第一件事,说的其实是规模效应和管理技能点的问题。

一个熟练写代码的高级开发,也许可以给项目组里的三四个初级开发指导技能,设计模块并协调分工,分派工作,但一定无法用同样的方式给500个开发分派工作。一个团队内的评审流程,也许5人团队可以跑,但在50人的部门则会显得内耗极重,效率奇低。

我见过很多人,简单的把管理理解成派活,指派任务并且在下属干得不好的时候,发出「还不如我自己来」的抱怨,一边你也不行他也不对的喷。像个负载均衡转发器,没啥技术含量,转发,报错,不粘锅。

不同的规模面对的困难是截然不同的,管5个人,500个人,50000个人,14亿人,你觉得呢?

于是同时,就需要加上另外一个底层逻辑:层级和责任。

你一定见识过往下甩锅的领导,也可能见过出了事儿但安然无恙的高管。如果举个更直接的例子:你的部门有500个人,如果这500个人加在一起干的不好,无论你自己表现如何,年底就开除你。

你该怎么办?

管理能力,大部分时候指的应该是制度流程框架的设计能力。好听一些,叫顶层设计,不好听一些,如何靠运作确保不要产生大锅。你需要清晰的知道你的团队,你的部门的职责是什么,边界在哪里,资源有哪些,如何被考核。进一步的,考虑最合适的分工,工作流程,把控的要点(审批点和后追溯的点),上升和兜底的路径。确保你的人力可及的情况下,能够最有效的把握团队工作的进展,又不给团队的实际工作,带去过多的额外工作量(管理成本)。

一个代码的循环体内如果增加任何一点额外开销,整个程序就可能性能变得奇差。管理也是如此,管理也是个技术活。

科技管理是个很大的话题,研发管理,架构管理,项目管理,服务管理,生产运维管理,每一个细分的领域都可以写本书。

但管理的核心目的是风险可控效能规模化。

比如生产运维管理,你需要什么样的制度和流程,可以保障风险有效揭示,平台持续改进;研发管理如何让研发团队质量可控不受个体差异影响。

企业需要专家,也需要管理人员。虽然现实生活里这两个角色经常处在互道傻逼的状态……这个,就更是Long Story了。

先到这里吧。

Built with Hugo
Theme Stack designed by Jimmy