为什么我会主动给一个年轻程序员加薪、晋升?
2年来我把团队里一个初级开发晋升到了中级开发同时给他加了工资年终奖也比之前高了不少。很多人经常问领导提拔一个人到底看什么我不想讲太空泛的词比如责任心、执行力、主人翁意识之类的。我直接讲一个真实案例。看看这个年轻人做了什么让我主动去给他争取晋升和加薪。他是2024年加入团队的。刚入职的时候我和大多数管理者一样先给他安排一些相对简单的需求。我有个习惯。团队所有任务分配情况我都会记录。从2024年一直记录到现在每个需求是谁负责、完成情况如何基本都能追溯。他接到的第一个任务是门店物料报损支持撤销功能。当时他提交的核心代码大概是这样的/** * 撤回报损单 */publicvoidcancelLossesDocs(CancelLossesDocsCommandcommand){LossesDocsAggregateRootrootLossesDocsRepository.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年。我已经开始把一些大型模块直接交给他负责。例如门店排班系统门店物料制作预估系统从设计到落地基本由他独立推进。我很少再去具体干预实现细节。结果也都做得不错。所以回到最开始的问题领导提拔一个人到底看什么我的答案是不是看你会多少技术。也不是看你平时是不是很会说话。而是看你能不能持续承担比当前岗位更大的责任。简单任务做好了给你更复杂的任务。复杂任务做好了给你更大的项目。项目做好了再给你更大的系统。当领导发现你总能把略微超出自己能力范围的事情做好。那么晋升、加薪、更多机会往往只是时间问题。