为什么我会主动给一个年轻程序员加薪、晋升？

2年来，我把团队里一个初级开发晋升到了中级开发，同时给他加了工资，年终奖也比之前高了不少。

很多人经常问：

领导提拔一个人，到底看什么？

我不想讲太空泛的词，比如责任心、执行力、主人翁意识之类的。

我直接讲一个真实案例。

看看这个年轻人做了什么，让我主动去给他争取晋升和加薪。

他是2024年加入团队的。

刚入职的时候，我和大多数管理者一样，先给他安排一些相对简单的需求。

我有个习惯。团队所有任务分配情况，我都会记录。

从2024年一直记录到现在，每个需求是谁负责、完成情况如何，基本都能追溯。

他接到的第一个任务是：

门店物料报损支持撤销功能。

当时他提交的核心代码大概是这样的：

/** * 撤回报损单 */publicvoidcancelLossesDocs(CancelLossesDocsCommandcommand){LossesDocsAggregateRootroot=LossesDocsRepository.findRootById(command.getDocsId());if(Objects.isNull(root)){throwBusinessException.of(ErrorEnum.PARAM_INVALID_VALUE.getCode(),"报损单不存在!");}if(!newSystemGrayProperties.isDocsCancelFlag()){throwBusinessException.of(ErrorEnum.AUTH_FAIL.getCode(),"门店{"+root.getShopName()+"}还未上线该功能!");}// 1. 单据取消root.cancel(command.getUserName());// 2. 同步库存中心this.syncToStockCenterCancel(root);// 3. 更新数据库LossesDocsRepository.updateStatus(root);}

我第一次看到的时候，感觉很爽。不是因为用了什么高级技术。而是因为结构非常清晰。

验证参数、执行业务、同步库存、更新数据库。整个流程一眼就能看明白。

这些年我接触过很多年轻程序员。工作两年左右，能把代码写得这么干净的，其实并不算多。

于是我顺手问了他两个问题。

• 第一个：如果单据取消成功了，但调用库存中心接口失败了，怎么处理？
• 第二个：库存中心取消成功了，但数据库更新失败了，又怎么办？

他当年的回答是：

第一个问题不存在。因为这里采用的是DDD的写法，root.cancel()只是修改内存对象状态，并没有立即更新数据库。真正的数据持久化是在最后一步。所以不会出现业务已经提交但数据库还没更新的情况。

第二个问题的话，数据库更新是按照主键更新，正常情况下不会失败。除非数据库本身出现故障。

这个回答在当时是ok的。说明他对自己写的代码是理解的，不是照着模板拼出来的。

当然，我还是给了一个建议。同步库存中心失败时，最好提供补偿机制或者重推工具。这样后续排查和恢复会方便很多。

后来这个功能上线了。一直运行到现在，几乎没有改动过。稳定性非常不错。

接下来，我又陆续给他安排了一些类似的任务。

结果都差不多：

• 交付质量稳定；
• Bug数量很少；
• 出现问题响应很快；
• 态度积极。

对于管理者来说，这其实是一个很重要的信号。

因为只有当简单任务持续做得好，你才有资格接触更复杂的事情。

后来我决定再给他加点难度。我把一个涉及第三方系统对接的项目交给了他。

业务大概是：

门店下单后，需要同步给外部系统，由外部系统负责配送到门店。

从需求评审、技术方案设计，到开发上线，全部由他负责。同时我把他拉进了和第三方技术团队的对接群。让他直接负责沟通。

做过第三方系统对接的人都知道。这种项目比普通需求难得多。

因为第三方是不可控的。

很多问题不是你自己的代码导致的。你必须提前把各种异常场景考虑清楚。

当时我只给了几个方向性的建议：

• 监控和告警一定要到位；
• 充分考虑稳定性和异常流；
• 技术方案先和我过一次。

剩下的事情基本让他自己推进。

后来发生了一件让我印象特别深刻的事情。

第三方给出的方案是：

通过定时任务批量同步订单。

而他在方案评审时直接提出反对意见。他的理由很简单。

这家第三方公司同时服务很多品牌。如果所有客户都通过定时任务集中推送订单，他们的系统很容易在高峰期出现问题。

最终会影响到我们。

他的建议是：

改成实时同步。

产生一张订单，就同步一张订单。成功一单算一单。

我知道这件事以后，立刻支持了他的方案。

并要求第三方增加订单取消接口。我们这边实时推送订单，同时支持实时取消。

这件事情让我对他有了新的认识。因为从那时候开始，我看到的已经不仅仅是一个会写代码的人。而是一个会思考系统整体稳定性的人。

很多开发到了这个阶段，仍然只是执行需求。别人怎么说，他就怎么做。

而他已经开始主动独立思考：

这个方案是不是合理？有没有更好的方式？长期运行会不会出问题？

这种能力非常难得。

到了2025年。我正式提名他晋升中级开发，同时给他加薪2500元，绩效评定A。

因为在我看来，他已经具备了中级开发应该具备的能力。

而到了2026年。

我已经开始把一些大型模块直接交给他负责。

例如：

• 门店排班系统；
• 门店物料制作预估系统；

从设计到落地，基本由他独立推进。我很少再去具体干预实现细节。结果也都做得不错。

所以回到最开始的问题：

领导提拔一个人，到底看什么？

我的答案是：不是看你会多少技术。也不是看你平时是不是很会说话。而是看你能不能持续承担比当前岗位更大的责任。

简单任务做好了，给你更复杂的任务。复杂任务做好了，给你更大的项目。项目做好了，再给你更大的系统。

当领导发现：

你总能把略微超出自己能力范围的事情做好。

那么晋升、加薪、更多机会，往往只是时间问题。