A year ago, I had a great opportunity to give a talk about recruitment to job seekers and developers with 1-4 years of experience. I prepared content generally helpful for job searching or changing jobs. Although I tried to avoid focusing too much on "how to get hired," the topic related to recruitment inevitably felt somewhat materialistic, like the clanging sound of a factory. On the other hand, discussing something more fundamental felt beyond my capabilities and experience. I was also worried about making unnecessary assertions.

I was thinking about how my modest experience could offer practical help to those who need it. Recently, my nephew, who started studying development, asked me to recommend some books. I don't know if he'll become a developer later, but he seemed to be studying diligently. Thinking about what I should tell him if he seriously considers becoming a developer led me to wonder: If I could go back in time and start over as a developer with my current mindset and experience, how would I want to live? I thought this might be helpful to others as well. The theme became "If I were to live a second life as a developer?" This will likely be filled with very personal stories. Although subjective, perhaps there's something objectively helpful within them?

I wrote the text quite a while ago but hesitated and fiddled with it for a long time, letting over half a year pass. I'm finally publishing it now.

Study the Fundamentals More Diligently

Maybe not middle school, but I would have studied really hard in high school. Especially English and Math, I would have put in a tremendous amount of effort. Perhaps most people reading this have already passed that stage. Chronologically, it's too late. Even if that time doesn't return, I believe you can catch up sufficiently by consistently studying these alongside technology from the beginning of your career.

Most technical documents are initially written in English. Being good at English allows you to learn new technologies faster. Quantitatively, the majority of documents are in English. Stack Overflow also uses English. Proficiency in English enables more accurate searching and quicker comprehension of the results. Is that all? Since most programming languages use English, a good sense of English is crucial for naming identifiers. Most developers agree that naming constitutes more than half of development.

Being proficient in English opens up opportunities beyond Korea, including working abroad or for foreign companies. It creates the "chance" to work at global corporations. Many Korean developers are highly skilled, and with English proficiency, they are recognized anywhere overseas. I think I've managed to make a living as a developer until now partly because I studied English diligently. That doesn't mean I read fluently. I still encounter many unknown words, look them up in dictionaries, and use Google Translate. But I don't have a phobia of English. I believe English contributed more than 50% to how I make a living now.

Opinions on math vary among developers. The question "Is math necessary for developers?" yields diverse answers. I believe math is one of the factors determining the limits of one's development field. I love music and once tried creating virtual instruments using VSTi technology. While I had no problem adapting to the programming language or development environment, the mathematical concepts related to audio technology were overwhelming. I tried studying math diligently later, but I had a long way to go. My goal shifted slightly in the meantime, so I put it on hold, but I wonder if someone inherently good at math might have achieved something before their goal changed. It's incredibly difficult to overcome the status(?) of being a "math-avoider." Many books target this very point. I realized that math could be a stumbling block to entering the development field I wanted.

Recently, I told my nephew, who became interested in programming in middle school, that school studies are important, and he should especially get close to English and Math. Saying this, I recall hearing the same thing constantly in middle school myself. It probably won't be very effective.

Gain Broad Experience at a Small Company

First, I'd want to gain extensive experience at a small startup. Although my first life started at a small web agency, the industry environment has changed. So, I'd focus on building "our" service well at a small startup, accumulating experience in various tech fields. Startups vary greatly depending on their size, but a small one would likely offer diverse opportunities (out of necessity). Technically, relying on less division of labor, I could gain opportunities to challenge myself in various areas like BE, FE, server infrastructure, and mobile. If I stood out, I might get opportunities to lead certain parts or even become a team leader early on. In larger companies with well-defined roles, one might delve deeper into a specific area, but gaining diverse experience is harder. Leadership opportunities also tend to come later. That's not necessarily wrong. Either way, one eventually needs to become an expert in a specific, divided part. Diverse experience is a bonus.

In this field, which is constantly changing unpredictably, as it always has been, such diverse experiences can serve as a strong foundation for adapting quickly. This is especially helpful for someone like me, a non-major who transitioned from another field. The development area I'm currently in is chosen because I like it now, not because I couldn't do or found other areas difficult. I believe one should be able to switch depending on the situation or changing interests, just like Flash was abandoned after a word from Jobs.

Nowadays, benefits have become somewhat standardized upwards, so most places are decent. Salaries are okay too. Joining early after investment could even lead to a jackpot through stock-based compensation. It's a gamble, but even if it fails, the experience and career remain. As long as the salary is guaranteed, it's never a losing proposition.

Don't Be Too Focused Only on Development

This might vary depending on personality and interests, but I wouldn't solely focus on development. I am a developer and I like development, but ultimately, what we create are software products used by people. I want to create things that sell well. A developer's contribution isn't always limited to coding.

As one gains experience, skills beyond development become increasingly necessary. Being good at coding as a developer is a given, and dedicating the most time to learning and improving it is also natural. However, there comes a time when focusing only on the development skills "needed" for the current job becomes inefficient because you already know a lot. For example, a frontend developer studying only frontend. After about three years of diligent study combined with practical work, the efficiency drops. From that point, studying other languages or platforms becomes a way to broaden overall insight and perspective. But even that loses efficiency after a few years, and as seniority increases, expected capabilities and responsibilities extend beyond just development. Plus, you quickly forget things you don't use in practice. That's me...

So, from that point, it seems beneficial to also study other non-programming areas that can help in product creation, at least up to a cost-effective level. These are often called soft skills. I would pay attention to and develop skills needed for projects to run smoothly. Initially, I thought these weren't skills I needed right away, but I was wrong. I believe knowing them early on is good. They are competencies that can actually make you stand out more as a developer.

Furthermore, I'd want to take a greater interest in design and UX. As a frontend developer, I've learned a lot gradually through experience, but exploring books and lectures on these topics is like discovering a new world. There are many interesting books on design, including books specifically for developers. There are also fun books about drawing, like "Drawing on the Right Side of the Brain" (or similar concepts like "잘 그리기 금지" - No Good Drawing Allowed). :)

However, the most important thing is undoubtedly programming. Programming skills must be the foundation for everything. Therefore, programming should receive the most emphasis. But I would also prioritize and strive to improve soft skills with significant weight. We don't work alone, and ultimately, we're building products, not just code. The fact that soft skills are commonly needed in other professions is an additional advantage.

Get Along Well with Your Manager and the Company

This topic might be somewhat sensitive. These are all just my personal opinions.

I generally got along well with my direct managers, like team leads. I made efforts to connect with them on a human level, beyond just work. Not that I was a yes-man who just flattered them. That's not being close. Some might react negatively to the advice to get along with managers and the company. It might seem like willingly becoming a subservient pawn, a pathetic figure.

I believe one should appropriately leverage the manager and the company as a sort of service(?) for one's career. For that, a good relationship is necessary.

People who frequently hover around the manager often develop a negative image. It might seem like good opportunities only go to those with such connections, and they appear to be all talk. Well, that might be true in some cases. In such instances, the manager is likely incompetent. But mostly, it's a misunderstanding. Managers aren't fools. They keep people around because they are helpful. Conversely, being nearby makes you helpful. The same applies to the team member.

More interaction with the manager allows you to naturally communicate what you're interested in and studying, what kind of tasks you want to do, and what you're good at. This can lead to opportunities for related work. Frequent small talk about ongoing projects or tasks allows for more feedback and, ultimately, more help in various ways. This makes work smoother and leads to better performance. Successfully completing tasks builds trust with the manager, who then offers better opportunities or challenging tasks. The same pattern repeats. Because progress was continuously shared in both formal and informal settings, the manager understands the process better. Knowing the process behind completing a task makes a huge difference compared to not knowing it. When misused, this can be called politics.

Julie Zhuo, VP of Product Design at Facebook, says in her book "The Making of a Manager" that you should "treat your manager like a coach, not a judge." Because a team member's performance directly translates to the manager's performance, the manager wants the team member to succeed more than anyone. You should actively seek feedback, ask for help whenever possible, and share your concerns.

An organization where all members maintain such relationships with their manager would be the best kind of organization. It's the ideal for both managers and members. :) If, for any reason, a mutually amicable relationship cannot be maintained and instead turns hostile, moving teams or resigning quickly is the answer for both parties. There's no reason to endure it. Understanding differences has its limits; extreme differences seem irreconcilable. In extreme cases, it could lead to workplace bullying. Both team members and managers can be victims of bullying.

Share More Often

I would engage in external sharing activities like blogging, presentations, or lectures much earlier. Although I occasionally step in front of people, I suffer from severe stage fright when the spotlight is properly on me. So, early in my career, I avoided such activities using stage fright and lack of knowledge as excuses. I wanted to do it but was scared, telling myself "not yet." However, as my career progressed, tasks requiring me to convey technical knowledge to others increased, and I started naturally. Looking back, I'm glad I started, even if it was that way. My life as a developer changed significantly after actively engaging in sharing activities. It was immensely helpful, directly and indirectly. I still get nervous and tremble every time, but I regret not trying it even a little bit sooner.

Sharing isn't something only exceptionally talented people can do. You might think, "Who am I to share?" but precisely because you're not a "somebody," it's easier. The so-called celebrity developers are "somebodies," so they can't easily share just anything due to their significant influence. Anyone can share their knowledge or experience with the good intention of helping others. You might not resonate with many people. So what? People can have different thoughts. Even if you share incorrect information, many people will point it out and guide you correctly. You learn from that too.

The fact that you learn more yourself through sharing is well-known. Preparing to share in any form helps you discover and fill your own knowledge gaps. Einstein supposedly said, "If you can't explain it simply, you don't understand it well enough," and Richard Feynman reportedly restudied concepts until he could explain them easily. Their words aren't always right or universally applicable, but they resonate deeply and can at least provide motivation. Insights about sharing knowledge aren't limited to them; they can be found everywhere.

Thinking more practically, the self-promotion effect through sharing cannot be ignored. Most well-known "monsters" (highly skilled developers) became known through sharing. One might adopt the humble mindset of a lonely indie musician, thinking, "I don't care about popularity," but in today's world, sharing increases the likelihood of gaining advantageous conditions in various ways. I want to emulate the monsters, even just a little – both international and local ones.

Sharing isn't about doing it well or poorly; it's about having done it or not. I'll just do it.

Exercise More Diligently

Looking back at my younger days, even younger than now, filled with passion, I realize that physical strength is paramount. I didn't even know its importance back then, but I now keenly feel that passion must be backed by physical stamina. Trying to use spare time after work is futile if you're already exhausted. People say passion decreases with age, and I wonder if that's also because physical strength declines. There's nothing like exercise for building stamina. You can also build a strong body and prevent various illnesses. Furthermore, it's known to have positive mental effects. Aerobic exercise is even said to generate brain cells.

Dr. Sanjay Gupta, who has studied the brain for a long time, suggests several methods for maintaining a young, healthy, and sharp brain in his book "Keep Sharp." Among them, regarding exercise, he advises: "Do strength training at least 2 days a week and exercise for at least 30 minutes on at least 5 days a week." He mentions that the 30 minutes of exercise on 5 days can be sufficiently met by walking. As someone who primarily did weight training, this book (and a herniated disc ㅜㅜ) prompted me to incorporate more aerobic exercise.

It's great to see that junior developers these days seem stylish and take good care of their bodies. Yes, let's shed the outdated, messy image associated with developers—plaid shirts and horn-rimmed glasses—and cultivate an image of being healthy, stylish, cool, smart, and sharp, yet warm to our loved ones :) Let's take care of ourselves, not just our computers.

I learn a lot these days from MZ generation developers who are taking good care of both their careers and themselves.

Conclusion

Thinking about it now, the environment will likely be different by the time my nephew considers development as a career, so this advice might not be very helpful. The importance of English could also change with advancements in translation technology. Will the jobs of developer and programmer even exist?

I've omitted obvious points like "study consistently," "be more technically curious," and "read more books." Anyone who loves their work and has passion does that anyway, not just developers.

In reality, there's no second chance :) So, to add one more thing, it seems necessary to always seek diverse experiences to cultivate a Plan B. Since there's no second chance in reality, you need at least a Plan B. There's the saying "Dig one well," but also "Don't put all your eggs in one basket." It feels like all proverbs and sayings exist as opposing pairs, like swords and shields. Instead of focusing solely on the job, we should look at the larger forest of life and dig our well in a direction that suits us.

I used "developer" in the sense of "programmer." I debated replacing it with "programmer," but "developer" is used more broadly these days, so I kept it. I agree that everyone involved in product development—designers, planners, etc.—are developers. I've added more specifics related to programmers among them.