Why I Proactively Gave a Young Engineer a Raise and Promotion

For the past two years I have taken a junior developer in my team from a beginner to a mid‑level engineer, increased his salary, and awarded him a higher year‑end bonus.

His first assignment was to implement a store‑material loss revocation feature. The core method he wrote is shown below:

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

I was impressed not because of any fancy technology but because the structure was extremely clear: validate parameters, execute business logic, sync to the inventory system, and finally update the database. The flow can be understood at a glance.

After reviewing the code I asked him two questions:

If the document cancellation succeeds but the inventory‑center call fails, how would you handle it?

If the inventory‑center sync succeeds but the database update fails, what then?

He answered that the first situation cannot occur because, using a DDD approach, root.cancel() only changes the in‑memory state; persistence happens in the final step, so the business operation is not committed before the database update. For the second question he said the database update is a primary‑key update that normally does not fail unless the database itself is down.

I suggested adding a compensation mechanism or a retry tool for inventory‑center failures to simplify troubleshooting and recovery.

Subsequent tasks he handled showed the same pattern: stable delivery quality, very few bugs, rapid response to issues, and a proactive attitude.

Later I assigned him a more complex project: synchronizing store orders to an external delivery system in real time. He was responsible for the entire lifecycle—from requirement review and technical design to development, deployment, and direct communication with the third‑party team.

Because third‑party systems are uncontrollable, I reminded him to consider all exception scenarios, set up proper monitoring and alerts, and ensure stability. I also asked him to run his technical solution by me before implementation.

During the design review the third‑party proposed batch‑syncing orders via a scheduled task. He immediately opposed this, explaining that the partner serves many brands and a batch approach could overload their system during peak periods, ultimately affecting us. He advocated for real‑time synchronization—pushing each order as it is created and adding an order‑cancellation API.

I supported his proposal, and the partner added the cancellation endpoint. This experience showed that he was not only writing code but also thinking about overall system stability.

By 2025 I formally promoted him to a mid‑level developer, increased his salary by ¥2,500, and gave him an “A” performance rating. By 2026 I began assigning him large modules such as the store scheduling system and the store material forecasting system, which he drove from design to production with minimal intervention.

The answer to the original question—what leaders look for when promoting someone—is not the number of technologies known or how well one talks, but the ability to continuously take on responsibilities beyond the current role. Consistently mastering slightly harder tasks earns trust for more complex work, larger projects, and eventually larger systems, making promotion, salary increase, and new opportunities inevitable.