35岁程序员真的会失业吗

为什么会有35岁程序员失业的说法，为什么不是34岁或36岁呢？由于我自己之前也是程序员，其实即使现在也还是，虽然不怎么写代码了，但是写代码的能力一直都没有丢掉，而且也还指导下面同学进行代码设计。由于从事的是程序员这个职业，由于近十几年业内会有一个说法：35岁程序员真会失业吗？。我做技术管理的时候，也会有很多同学问我这个问题，时而导致他们非常困惑和焦虑。因此，我用亲身的经历来和大家说说我个人的理解和思考。我会从两个方面来进行说明：

1、为什么会有35岁程序员失业的说法

2、如何脱离大龄程序员的困惑和焦虑

为什么会有35岁程序员失业说法

为什么会有35岁程序员失业的说法，为什么不是34岁或36岁呢？其实“35岁”只是一个代名词而已，重要的不是多少岁，重要的是程序员本身输出的个人价值，和多少岁没有太大的关系。

最本质的原因是：35岁程序员的能力和25岁、30岁的程序的能力出现了同质化。

同样这里35岁、25岁和30岁，并不是指的年龄，而是指的不同工作年限的程序员。有的年轻程序员可能只是工作了3-4年左右，有的程序员可能工作了10年甚至15年，或更长时间。

首先我们来思考一个问题。如何来衡量一个程序员的价值？程序员最终的交付的是按业务规则运行的程序，也就是代码。我们衡量一个程序员交付的价值一般有两个标准：

1、代码完成的时间成本。

2、代码完成的质量好坏。

时间越短，质量越高，质量不仅包含代码测试和上线的BUG率，也包括业务灵活扩展性以及性能等多个维度判断标准。

我们尝试思考一个以下两个问题：

1、一个35岁程序员和一个25岁程序员，有没有可能在代码完成的时间上，35岁程序员比25岁程序员要快2倍、3倍甚至5倍以上吗？

从事程序员职业或相关职业的同学都知道，单纯从代码输出时间成本，一个普通的35岁程序员很难比一个25岁程序员快多少，相反有可能还要慢。因为25岁程序员加班通宵不要命的码代码是常事，身体扛得动，而35岁程序员身体素质普遍自然是比不过25岁程序员的。

2、从代码完成质量角度来看，35岁程序员可以比25岁程序员要好2倍、3倍甚至5倍以上吗？

从质量好坏的层面来看，一个经验丰富程序员要比一个菜鸟程序员写的代码质量会好很多，包括对于业务的理解、代码扩展性、健壮设计等。但是，大家要清楚，不是每次写代码都是从一个全新的从0开始的，对于系统架构设计，技术选型、以及代码工程规范、代码设计标准等其实都已经确定了，能够给到程序员个人去发挥的也只有局部的模块和功能的设计。

所以，即使作为一个经验丰富的程序员，自认为觉得比其他程序员代码设计的都好，但是很少有人做到将代码设计的技术价值的好，显性转化为的业务价值的好。

有的程序员说，15年的行业经验，其实15年只是工作年限，并不是所谓经验年限，如果从解决问题的经验角度出发，可能5年的编码经验，用了15年。因此，经验其实是比较难量化为显性的个人价值。

因此，作为一个35岁程序员在与25岁、30岁的程序进行价值比较的时候，既不能在完成时间有成倍效率，又不能在代码质量上取得显性化的业务价值。所以，在老板或公司高层的角度来看，就是个人能力出现了同质化的竞争，在能力和实际可用经验差不了太多的情况下，越年轻的程序员无论从薪资成本，工作与家庭时间的平衡、身体素质等多方面还是有较大优势的，单纯高龄程序员并没有较高的替代成本。

因此，很多公司HR从投入产出比的角度，开始慢慢淘汰价值一般的大龄程序员，35岁程序员失业的这个事情也就慢慢行业内传开了。其实，从本质上就公司或老板的角度来看，希望能够使用投入产出比更好的员工。

如何脱离大龄程序员的职业发展困惑和焦虑

通过上面的描述，大龄程序员的困惑和焦虑来自于，程序员能力的充分同质化竞争。最近5年，每年计算机相关的大学毕业生约为45W左右，这些毕业生大部分都会进入软件或互联网行业，对于任何一个行业，从业者数量都是一定的。因此，每个行业到了一定的周期都会淘汰出一部分从业者出局，特别是在全球大环境持续低迷，很多软件或互联网公司进行大规模裁员的情况下，加速了这种淘汰。

既然我们知道了大龄程序员面临最主要的挑战就是与年轻程序员能力同质化的编写和设计代码层面的竞争导致。因此，就不能只在单一的维度进行代码设计层面能力竞争。从程序员从业务能力、技术能力和管理能力三个层面进行系统化的分析。

1、业务能力：长期聚焦行业与业务领域，成为领域专家，来构建个人能力壁垒

单纯的技术没有价值，只有把技术成果显性转化为业务成果才会有价值，技术的价值需要业务价值来证明。因此，对于业务了解的深度，能够更好知道，哪些业务环节是可以通过技术手段来取得较好的业务成果。

业务能力：是指程序员对于所服务行业以及业务了解的深度和广度，通过自己对于行业和业务的理解，以技术的载体，将技术运用到实际业务中，并显性化的转化为业务成果。

比如：我是从事于供应链，而且还是汽配供应链，因此，对于中国汽后市场以及汽配行业本身的了解的深度，以及汽配供应链业务的熟悉程度都非常重要。例如：汽配行业的本身的一些周期与规律，上下游利益关系，行业内头部企业盈利的模式，从业者的特点等，至少需要入行，对于行业的有一定的深度了解。

对于行业了解后，就是具体的汽配供应链业务，对于供应链业务领域只是进行深耕，不仅仅了解业务功能和流程，还要了解业务功能和流程背后的原因。因为最终一个业务是否成功，不在于技术本身，而是在于同样的模式下，业务本身的效率和成本是否能够优于竞争对手。而如何运用技术手段对于业务提效降本，则是技术显性化转化为业务成果的表现。在业务什么时间点、什么地方使用什么技术手段，能够起到提效降本的成果，则需要你对业务甚至行业有宏观和微观有深入的了解。

因此，一个大龄的程序员，一定是要在某个业务领域，最好能够成为这个领域的业务专家，至少也要成为在从事这个行业和业务的程序员里面，最懂业务的TOP存在。

因此，需要你长期聚焦在某个行业的业务领域里面，沉淀出对于行业和业务的专业知识和能够落地的数字化认知。否则，你的业务领域的能力壁垒很容易被年轻的程序员，在短时间内超过。做需要长期积累的事情，才会随着时间的推移有长远价值。

2、技术能力：做“十”型技术人才，既要有技术的深度和广度，也要有技术的高度。

程序员能力的同质化，导致高龄程序员被逐步淘汰。因此，对于高龄程序员来说，需要构建自己差异化的能力。

对于做技术的人来说，非常在意于技术本身。因此，会花大量时间去研究纯技术。例如：XX消息中间中间件底层原理，Spring框架底层实现源码、TCP协议分层原理、socket通信底层原理等等，技术对于一个程序员是非常重要的，也是一个程序员的根本。

在职业生涯的早期，熟悉这些技术的底层原理，会让你做好基础的代码编写工作，能让你胜任目前的工作。但如果三五年后，你仍然将全部注意力放在技术细节上，就要小心了。对于一名追求成长的技术人来说，只从技术维度思考问题是不够的。这只能让你胜任目前的工作，但不能让你变得卓越。

技术本身就存在不同的维度，编写基础代码仅仅只是技术工作中一项比较基础的工作，而不是技术的全部。还有架构设计、业务领域专业等方面也是需要非常专业的。

技术不仅仅有深度和广度，还有高度。所谓的高度，就是跳出基础的代码编写维度，去思考更高层维度的架构设计、能够根据自己掌握的业务领域知识，结合信息化技术手段，让技术发挥出更大的业务价值。

架构设计对于应用系统的稳定性和性能、业务扩展性和业务兜底起到决定性作用。

技术架构设计决定一个应用的稳定性和性能的上限和下限。

一个系统的大面积的崩溃或宕机，最本质原因是架构上的缺陷，而不是局部某个代码BUG导致的。系统的可用性、健壮性、安全性一定是架构上需要去优先思考的，特别是对于一些异常和极端场景下的突发问题，需要在架构设计上能够有应对方案。就好比，两军对垒，不是依靠某个士兵的强弱而起决定性作用，一定是靠将帅结合当下的作战环境的采取适合的谋略而取胜的道理是一样的。

架构设计决定了业务的扩展性。

关于架构设计可以参考我的《大白话聊聊系统架构设计》就知道，对于行业和业务领域理解的深度，就决定了你对于业务本质的看法，对于业务的抽象能力也就是越强，就能够很好的识别业务中变与不变的元素，识别元素与元素之间的关系，从而达到快速业务扩展性的架构目，而是习惯于基于单个业务需求写代码，而不是基于架构设计写代码，反正来了需求先实现了再说，尤其是在业务刚刚起步时最终导致后期新需求的研发进度速度严重下降，影响业务的落地节奏和业务机会的时间窗口。

所谓扩展性设计，是为了支撑业务快速发展而出现的概念，目的是保证在企业发展的不同时期，在业务复杂度相近的情况下，业务上线所需要的研发时间不会大幅增加，甚至是基本不变的。

基于零散需求的代码实现

基于良好架构设计的代码实现

架构设计一定要为业务底线问题兜底。

除了系统的可用性和性能外，好的应用架构设计在设计的时候一定要能够为业务底线问题兜底。什么是业务底线问题？

如果你设计的是库存系统，那么你就要保证库存的准确性。如果设你计的结算系统，那就要保证你的最终业务结算金额是准确性。如果库存数据不准确，如果结算金额不准确，就算功能和性能再强，业务也觉得系统体验非常差，因为库存和结算资金的准确性就是业务底线。

如何保证库存和结算金额的准确性，并不是靠下面单个程序员的能力，而是靠架构设计去保证。如果意识到，库存和资金正确性的重要，在架构设计上考虑设计库存对账子系统，资金稽核子系统，时刻去发现和保证库存和结算资金的准确性。

因此，对于业务底线问题，一定架构设计去兜底的，刚开始就是需要把业务底线问题解决，然后通过不断细节的迭代，最终对于整个系统和业务起到至关重要的作用。

3、管理能力：做好角色转换，目标、团队一个都不能少。

可能有很多做技术的同学会说，我们技术做的很好。为什么要做管理？管理很烦，又要写PPT，又要汇报，还有沟通与人员管理，我就只喜欢安安静静的写代码，走纯技术路线发展的。

作为程序员，安安静静写代码确实没有错，但是一个写代码能够完成的完成的事情非常有限，有许多工作价值，只能靠团队的力量实现，个人能力再强大也于事无补。管理的价值会随着团队规模的扩大而增加，一般会超过大部分技术专家的价值。技术管理是个人技术能力的放大器。

也还有很多程序员虽然是做了技术管理，但是做的事情还是和之前没有太多变化，写代码的时间确实少了，但是救火的事情，处理日常事务的时间多了，整天东忙忙，西忙忙，慢慢觉得个人不能聚焦在技术上，整体干一些杂事，个人无法得到成长，然后就慢慢的焦虑。其实，这个本质上就是没有一个只写业务代码的程序员的角色，转变成为一个技术管理者的角色。技术管理，就好比，你驾驶一辆马车，从一个地方到另外一个地方。总结起来就是需要做这五件事情：

首先，想要驾驭马车，就得先跳上马车，而不是认为自己还是马。这个叫角色转变。

其次，目的地在哪里，该走哪条路，朝哪个方向行进，如何到达。这个叫看方向，定目标。

第三，抓住马缰，关照好马的状态和组织分工，这个叫带人，也叫团队和组织建设。

第四，挥舞马鞭，协调好整个马队的前进方向和节奏，让马匹一起用力把车拉到一个个里程碑和目的地，这个叫做事，也叫任务管理。

最后，车夫需要关注马匹状态，以及马车之外的其他环境要素进行互动和沟通。这个叫管理沟通。

其实，管理和技术一样，都是一门专业。技术管理只是管理的是技术人员而已，好的技术人员并不等于好的技术管理人员。技术水平好的，并不等于管理水平也好。

写在最后的话

高龄程序员首先需要通过个人自身对于价值贡献的思维进行思考，一定要将技术能够转化为显性的业务价值，才能够让技术本身具有价值，因为业务是根本，技术脱离了业务其实一点价值都没有。其次，不要给自己设限，不要对于具体工作内容进行设限，有助于提升自己业务能力、技术能力和管理能力的事情和任务就要去积极的做和思考，然后聚焦在某个业务领域，不断深耕，构建出专业壁垒。只有这样才能摆脱底层的低水平技术能力的竞争，才能够让自己的个人价值和可替代性对比普通的程序员有比较大的优势。

因此，作为一个能够给公司带来业务价值的程序员，在任何年龄阶段都不会失业。