Delivery Product Development Team Establishes 'Root-Cause-Focused' Development Culture Through Junior Debugging Study

The Delivery Product Development Team conducted a 10-week debugging study to strengthen the capabilities of junior developers. The program consisted of theoretical learning and hands-on case analysis, focusing on building the habit of identifying root causes rather than simply resolving surface symptoms.

Study Structure and Debugging Principles

The study was divided into 2 weeks of theoretical learning and 8 weeks of hands-on analysis. In the theory phase, participants learned the debugging mindset through Inflearn conference presentation videos, and in the hands-on phase, the study ran for 1 hour each week following the order of topic selection, individual analysis, discussion, and retrospective.

Participants followed the 5-step process used by debugging experts:

1. Define the problem
2. Define normal behavior
3. Build a minimally constrained environment and observe
4. Search for causes
5. Form and verify hypotheses

In particular, they adhered to the principle of allocating 60% of debugging time to root-cause analysis, and emphasized the attitude of not trusting unverified hypotheses and always confirming them through logs and monitoring metrics.

Hands-on Case: Resolving a Redis Serialization NPE

In the hands-on study, participants tackled a case of an intermittently occurring NullPointerException (NPE) during the login process. The error occurred when java.time.LocalDateTime.format was called in LocalDateTimeAdapter, and the stack trace passed through the Gson and Spring Data Redis libraries.

In the initial analysis, participants formed various hypotheses, such as a Spring Boot version update or differences in @PrePersist timing. However, through feedback from Han Kyung-hoon, they recognized the importance of gathering clues, and ultimately confirmed that some of the date fields of the Token object (expirationTime, regDate, updDate) were being passed as null during the serialization process for storage in Redis.

Study Outcomes and Improvements

Through this study, participants internalized the following debugging tips:

• Prioritize clue-gathering: They learned that systematically collecting error messages, stack traces, and reproduction conditions is the first step in debugging.
• Set clear goals: By setting specific goals such as 'find the cause of the API 500 error,' they reduced unnecessary exploration time.
• Understand system characteristics: They realized that understanding how components behave first is necessary to distinguish 'fake errors' caused by intended exception handling or system characteristics.

Participants such as Choi Ji-su and Kim Kyung-rok reflected on their past habit of approaching problems with a narrow perspective, and assessed that their ability to synthesize clues from a broader perspective had improved. They also derived an improvement plan to enhance logging so that, when an error occurs, the fields assigned null values are clearly recorded.