On the Skills and Growth of Junior Developers (feat. Done is better than perfect)

This piece organizes the skills junior developers need using an analogy to Korean, English, and Math. Korean represents the ability to communicate clearly with colleagues, English represents the information-gathering ability to read the latest documentation, and Math represents the logical thinking needed to structurally interpret business logic.

In practice, low-context communication is important. Rather than saying something like "please take care of that," which leaves a lot of room for interpretation, you should specifically convey what needs to be done, by when, and in what context, in order to reduce trial and error.

When solving problems, don't look at just one perspective—explore information through multiple paths.

• Check downsides, points to watch out for, pitfalls, and gotchas alongside positive information.
• Narrow the scope using search operators like site:stackoverflow.com.
• Check GitHub Issues to understand problems that recur in real-world use.
• Subscribe to newsletters or relevant blogs to keep up with trends consistently.

Whatever you learn must be left as a record. Using team Wikis, code repositories, and comments to document why a certain decision was made and the reasons for any unusual handling reduces the learning cost and the cost of repeated questions for the next person.

In particular, comments and logs are tools for leaving not just "what it does" but why it's needed. For parts with domain- and time-dependencies—such as card number masking, Luhn algorithm validation, or a batch job running at 2 AM—the context should be documented alongside the code so it's easier to understand later. The same applies to exception handling: when a failure occurs, enough information for troubleshooting should be recorded, such as the card number, amount, PG company, error code, and message.

Questions are not something to be avoided—when done properly, they're the fastest means of learning. However, before asking, you should first check the Wiki, messenger, code, and search results, and when you do ask, you should summarize what you've tried and the situation so you can get an answer quickly. After receiving an answer, it's important to document it again for the next person.

Finally, rather than aiming for a perfect implementation, build an MVP first and improve it incrementally. A realistic approach is to first build a working feature, then add exception handling and logging, followed by performance optimization, architectural improvements, and tests in sequence. Ultimately, Done is better than perfect doesn't mean doing things carelessly—it's a strategy to maintain the speed at which learning and improvement continue.