I believe it's good practice to update your resume at least quarterly, reflecting on the past quarter's achievements and planning for the upcoming one.

It might be helpful to think of a company as a place where you not only receive a salary but also generate achievements to enrich your career. If you think this way, you can never work passively. Instead of just doing what you're told, you proactively look for tasks that need doing, with eyes wide open.

A proactive work attitude means not just performing assigned tasks, but elevating them into meaningful achievements. Even with assigned work, you can find areas for improvement, identify problems, or discover efficient solutions, transforming an unremarkable task into a technically significant milestone in your career.

For example, find aspects of what you've studied, are currently studying, or plan to study that can be applied to a project. Then, you can propose to your team lead:

"There are some issues in the project like this, and I'd like to try improving this part in this way. This improvement would bring these benefits. Please give me X amount of time."

A team lead would likely welcome such an attitude with open arms. In reality, I've often seen people who find areas for improvement themselves and turn them into their own tasks grow significantly. Of course, not everything will be accepted, but such a proactive attitude will always be highly valued.

As you gain more experience (increase in years), this work attitude becomes less of a choice and more of a role requirement. However, there are many cases where individuals fail to perform this role properly, regardless of their years of experience. Ultimately, even tasks related to operations or maintenance can be transformed into significant achievements worthy of a resume through a proactive attitude and approach.

Periodically reflect on whether you've had sufficient achievements, and set plans and short-term goals to create specific achievements through upcoming tasks. This establishes both the direction for your career achievements in the next quarter and the direction for additional areas you need to study.

Rather than vaguely holding onto large goals and just believing you can achieve them, as often preached in self-help books, I think it's more important to frequently set immediate, short-term goals, achieve these small targets one by one, and agilely assess your direction. Things don't happen just because you believe; they happen because you act.

I believe you should approach your job with the intention of enriching your resume. The company, in a way, is a social service that helps build your career :)

Saying this might make me sound materialistic, but I believe working this way is a win-win for both the company and myself. Achievements made for the company also become achievements for me. And the reverse is also true.

Whenever you're doing work for the company, first think, "How can I turn this into a good achievement for my resume?" If you ponder this, you'll likely find respectable achievements even in small tasks. This doesn't require extensive skills; I think it's just a difference in mindset.

Technical Achievements

For developers, simply listing technologies isn't enough to represent achievements. Even if you explain the list descriptively, it doesn't change the fact that it's ultimately just a list. For example, stating "used X API from React" is information that actually credits React for being good.

Merely stating that you used a tool or technology isn't appealing on its own. A resume is ultimately like an advertisement. It's an ad appealing to potential employers to buy your time.

If using a specific technology in a task is itself an appealing point, you need to make the reader understand why that technology is appealing, making them interested.

For example:

• Did you create the technology yourself?
• Did you improve an existing technology?
• Did you apply a technology with a high degree of difficulty?
• Were there trials and tribulations in applying the technology?
• Did you perform meaningful work to ensure harmony with existing code?

Through such details, you need to create a narrative flow explaining what benefits and improvements resulted after the technology was introduced, how much you grew as a result, and how the company or service grew.

Trying to cram all this into a single task description can become too rambling, so it's best to leave only the emphasized points for each task.

Finding Achievements

Many people seem unsure about what to write as achievements for their tasks. Fundamentally, company work, or 'work' in general, is about using (selling) your time to solve a problem. If you solved the problem, preferably well, and achieved good results, that's a good achievement. However, simply stating the conclusion of the achievement makes it seem like just a claim. Something like "Successfully developed a chatbot using ~" is a claim. You need to appeal through the process and flow that serve as evidence, allowing the reader to infer the achievement.

1. What were the difficulties encountered while working on the task?
2. How did you resolve those difficulties?
3. What improvements or insights did you gain as a result?

If you're unsure what constitutes an achievement, start by recalling the most difficult aspect of the task. Think about what you believed was the root cause or origin of the problem, and recall the processes involved in solving it. Feel free to jot things down. What improved because of your solution? Or, even if solved, were there points for further improvement? Did you realize something new during the process of identifying and solving the problem? Something you didn't know before?

Write down the points you just recalled, then organize and trim the content, removing redundancy and rambling details to leave only the core essence – that's your achievement.

Regarding redundancy, let me clarify one more thing. Redundancy isn't just about avoiding repetitive sentences (though that's obvious, haha). For instance, imagine you highlighted skill or achievement AA in project A. It's likely that this skill or technology, successfully applied in project A, was also applied similarly in a new project, B. That is unless an improvement point for AA was discovered in the meantime.

In such cases, people often copy the description from project A's list and paste it into project B's description. Because, after all, it was applied in both. But think from the reader's perspective: They've already acknowledged your experience from project A, thinking, "Ah, this person has this experience, so they'll be good at this." Then, they see the exact same content again under project B.

This is what I mean by redundancy. You need to convey a lot within the short time someone spends looking at your resume. It's better to highlight different aspects for each task rather than repeating the same points.

Consistent Management

Once you have a sense of what constitutes an achievement for a developer, it would be great if, when undertaking future tasks, you take a moment to think, "What kind of achievement can I create from this task?" High difficulty presents its own kind of opportunity. Low difficulty also definitely has its opportunities.

Of course, it's easier to simply complete the task by producing only the defined result. It's comfortable. And not every task can produce a plausible achievement. However, while working on a task, consider whether the problem is properly defined, whether there's anything additional you, as a participant, should consider or do, and whether there's anything you, as a developer, could try or improve. Try to periodically capture that history in your resume and plan for the next steps. Doing so will, at the very least, help you form concrete thoughts about how you define growth and what direction you should take moving forward. Do this work at least quarterly.

Sometimes people ask about the optimal or most efficient way or format (template) to write about their experiences. I think there is no single best method or format for writing the most efficient, most optimized resume. Even if it were truly the best state, it would be hard to recognize. And writing about small achievements using a specific method and format doesn't turn them into large achievements. It seems most ideal to simply maintain the best possible resume for the present moment through consistent management. A resume that is constantly evolving through setting goals and improving the content, not the format.

Regarding things like "Resume templates that get you hired at big companies," which some people sell for money or use as clickbait for personal branding, it's probably best to just use them as a reference for readability. Constantly revising your resume for the sake of format is, I think, a waste of time. And large companies already have their own templates.

The resume is just the beginning of the hiring process. (Making a living is tough, haha) Consistently reviewing and revising it is sufficient. Let's not be too anxious and take it easy!

Conclusion

The title "Resume-Driven Career Development," inspired by Test-Driven Development (TDD), struck me as quite clever when it popped into my head during a workout, making me slap my forehead. But as I wrote, the content seems to have blended a bit.

Anyway, there are two things I want to emphasize: Let's maintain our resumes like code, periodically performing maintenance, self-reflection, and planning our careers strategically. And even for tasks assigned to us, let's proactively seek ways to improve and expand them, transforming ordinary tasks into extraordinary ones.