Carpe diem

Content written by quoting the presentation script.

Hello everyone, nice to meet you.

My name is rlaope, and I'm here to present under the title "Carpe diem." Nice to meet you all.

I'll keep my self-introduction brief. Yes, I'm a software developer.

I first encountered coding in elementary school in 2014, starting with Ruby, Visual Basic, and JDK 1.7.

I loved making games and disassembling computers. At that time, I launched an RPG game I made, and hundreds of thousands of subscribers even streamed it live on Afreeca. I was incredibly happy that someone enjoyed and played something I created.

I think that's when I started loving to create.

Then I went on to Gwangju Software Meister High School, where I made games, built servers, explored the school's infrastructure, and did a variety of other things.

After that, I started a project with the Office of Education. I secured about 4,500 in investment and even set up a dedicated room. If you ever get a chance to visit Gwangju Software Meister High School, please stop by.

And now, I'm working as a server developer at a company that provides an AI financial platform.

Currently, I'm focusing on studying AI engineering and running a team called Intelligence Labs, with the motto AZ (Arts & EnZ(gin)) – pursuing art and engineering. If you're interested, feel free to send a message.

My introduction was a bit long, wasn't it? #

If I speak without too much humility, looking back, I believe I've achieved a lot, but I've also failed a lot. From those failures, I think I've come to understand certain formulas for achieving results and for being chosen by others.

What do you all want right now? Is it a job? Self-realization? Self-realization, you say? Yes, I commend you for that, but first,

Most of you will probably aim for employment first. Of course, I did too.

Today's session consists of three parts.

One is how to get a job, software development principles, and self-realization and Carpe diem.

I really want to talk about point 3 the most, but I thought points 1 and 2 would also be good to hear, so I included them. Let's begin.

How to Get a Job #

Alright, let's dive straight into how to get a job.

Paradoxically, the way to get a job is not to desire a job. More precisely, it's about focusing on something fundamental other than employment itself.

I'm not saying don't wish for it. You can wish for it, but let's shift our focus from studying for a job to studying development.

And beyond getting a job, achieving something comes closer to you the less you desire it.

What does that mean? Having a crush on someone you like is a happy thing. It's full of hope.

But most unrequited loves converge to a 0% success rate. I was inspired by that.

Of course, such relationships cannot be expressed as a mathematical equation, but that's just an example. Let's be flexible.

To that extent, the direction of studying for a job is, paradoxically, not necessarily what companies want. Let's take an example: there are two candidates in an interview.

• A. Memorizes a lot and answers broadly on many topics.
• B. Dives deep into one topic, not broadly, but masters everything about that single subject.

One knows whether many scientific theories exist and their simple definitions, while B has a deep understanding of the theory of relativity.

Oh, that's too obvious~ Of course, they'd choose B, right? If you're a developer? Many seniors say this, don't they? Was B chosen simply because they knew this deeply? No, they were chosen because of that characteristic of diving deep. Because knowing broadly is also difficult; I think that's even harder and less fun.

Let's ask a question here: Why? Why? Why do they prefer someone who digs deep? Why do they hire them more?

You might think that way because you intellectually consider it true learning and a good attitude, but let's reconsider: why is that a good attitude? First, I'll explain the basis for preferring those who dig deep. Before that, I'll define "work" – what you'll be doing even after you get a job. As a developer, your job will be problem-solving. That's it. It's a continuous series of problem-solving. Nothing special. Shall I give an example?

A client inquiry comes in.

• Q. This page is currently inaccessible. (Problem)
  • A web page outage occurred.
  • The company's data center caught fire.
  • A server outage occurred. (Hypothesis) So we form a hypothesis like this. This is what A would be good at.
    • Joining table A and table B, but the condition was set incorrectly, leading to a join with C, causing data corruption. OOM occurred. A conditional statement enforcing strong consistency failed. (Cause 2)
  • Join A and B. (Solution) Yes, this is identifying the cause and the solution, which B would be good at.

Now, let's look at this. What do we need to achieve to solve this problem? Yes, the cause. You won't know the cause unless you dig deep.

Oh, there's an outage! So you'll answer, "Oh, either the data center caught fire, or the web page, or the server is faulty, or..."? You have to fix it.

You need to focus on problem-solving.

Next, I'd like you all to take the fast lane.

Let's say we have a graph of employment rates here. If we look at it as a standard normal distribution,

Those who get basic certifications and focus on memorization are, of course, competing here. But outside the standard deviation, there are actually fewer competitors. It's fine.

From mu plus one sigma, the competition rate significantly decreases, and employment chances increase. We want to play in that area.

The usual hiring process isn't resume submission-interview-employment, but often involves someone saying, "Wanna do it? (while drinking wine at a bar)," and you say, "Yeah, I'll do it," and you're in. Of course, I'm not saying you must do it this way, but those who can often pass resume submissions and interviews with ease.

So, what's the point? It's to take this fast lane.

So, how do you become such a person? It's through individuality.

Shall we predict the most common projects done by Meister High School students like us...?

On-campus dormitory management service, on-campus club management service. Oh, those are good, yes, they're good, but

I'm absolutely not trying to belittle them. I was also the technical team leader for a dormitory management service team in my school days. We struggled to get it nationwide, but it was abandoned and probably discarded by now.

Anyway. But I have to be blunt about this. There's a lack of individuality. No matter what technology you apply, it lacks individuality. What do people usually do after completing these? Yes, they apply new technologies, right? MSA conversion... DDD... event-driven... hexagonal clean architecture... It's a path to failure. Why? Because there's no reason, no answer to "why."

Because school projects have low traffic. Few users. The scope of problems for exceptional situations is easy to infer. That's why they lack individuality. So what do people usually do?

But it doesn't yield efficiency... This isn't just my opinion; in reality, over 10 interviewers, including CTOs, tech leads, and backend engineers who review resumes, aren't very interested and actually see it as more amateurish.

What's the basis for that? There's no "why." That's why they can't get hired.

What's truly regrettable is that the students who are good at development in school are usually doing all these things. That's why it's very unfortunate... We need to look at something more fundamental.

Why? Because getting a job is a continuous series of problem-solving that requires reasons, and a machine that can't provide proof and just spouts theories endlessly is useless to a company.

Of course, reading books is good. But don't brute-force all the content. It's better to pick and choose the information you want, like eating a meal.

And how do you achieve this individuality? I'll explain it in Session 3.

Oh, and it's different from the "Hongdae disease" (hipster syndrome). For example, there are people I call "tech hipsters."

"I develop with Rust, yeah. Java sucks, ugh." Why? I'd expect them to say something like, "The memory management features unique to Rust are so good that you can really feel the difference."

But they just say, "The syntax is clean, yeah." People who give answers like that think they're good at development, but ugh, it's not great. I think they'll probably realize why themselves... Yes, it's a pity.

What's the point here? Why is it needed? Have you made a rational decision about whether it's truly practically necessary?

How do I study? I take out a notebook. I call it my "magic grimoire."

I write down questions. I personally write questions about a topic, A.

• What is A? How is A different from B? How do you optimize A?

Write down the answers. If you can write it down and explain it, you've acquired that knowledge; if not, you don't know it. "Ah, I think I know it, but I'm confused..." Yes, you don't know it. Acknowledge it, meta-cognize, and be humble. Look again. Then it's yours.

You need to fill these empty spaces. Let's not fill an empty glass when there's no one to drink from it.

This will definitely strengthen your capabilities. Ask questions and answer the question marks. It's simple. Getting a job isn't hard. If you were hoping for an answer like, "Just study XX and then do YY in order, putting in ZZ hours," then please reflect on yourself and consider if you're avoiding this answer.

Alright! Some of you might be getting a headache here, especially me in the past. Ah... I know, but it's so frustrating to question everything. And it doesn't seem efficient. What should I start with? I want to do something urgently.

You want to do something, right? The answer to that is... I'll tell you in the Carpe diem session. For now, don't get a headache. I'll share and explain a few things while pursuing software development principles, especially in an agile manner. Just keep this mindset in mind and let's move on to the next session.

Software Development Principles #

I prepared this assuming most of you are developers. It can be seen as software development principles,

or product development principles. Please note that this content is based on my personal experience, so feel free to filter it as you see fit.

If something doesn't resonate, don't listen to it. I recommend picking and choosing only what you feel is necessary for you.

As mentioned in the employment session, I defined developers as a profession that solves problems. But is simply solving problems enough?

We're going to add an adjective before the responsibility of problem-solving: "rational."

Yes, rational problem-solving, rational decision-making. What this means is that we have limited resources, and within those resources, we must solve problems with the best efficiency and appropriate compromise.

When a typical problem arises, it's "Oh, if we just throw 100 million won at this, it'll be back to normal" vs. "We need to think a bit, but system optimization will improve performance this much and save about 100 million won in costs."

The latter is obviously better, and we need to achieve that.

Anyone can solve problems if they just throw money at them. However, determining if simply throwing money at it is acceptable and rational is a capability, and if it's not rational, finding other solutions is also a capability.

I will define the first principle as: engage in rational problem-solving.

The second principle is related to productivity.

You'll probably try various things to facilitate smooth team communication, such as documentation,

or using some productivity-enhancing tools, or using AI (which is good),

or creating a code review culture, writing PR templates, writing issue templates, and so on...

But as everyone has heard about over-engineering, things believed to improve productivity can actually lead to a decrease in productivity,

and sometimes the resources spent to implement a tool for productivity improvement outweigh the expected value after its implementation.

In fact, my approach is that I believe I can implement everything with just a whiteboard and a marker.

I think it's much more efficient to disseminate context through face-to-face conversations rather than formal code reviews.

The human brain has a characteristic of interpreting natural language text according to its own preferences during processing.

That's why sometimes we talk about different things, and only after applying it to actual production and encountering errors do we realize we were talking past each other.

Like the hot dog theory, where someone thinks of a hot dog with a sausage on a stick, and another thinks of a hot dog with a sausage between bread, and they talk about the commonality of "bread and sausage,"

what if they end up unable to understand each other when starting a business? Context is important, and sharing context is even more so.

Since not everyone can think like me, and I can't think like everyone, sharing this context prioritizes face-to-face conversation at the closest level.

This allows us to understand each other's thoughts and working styles, and eventually, text conversations with that person might achieve the same level of understanding as face-to-face conversations, right?

Face-to-face conversation doesn't just mean formal meetings. For minor changes, if you're curious about a piece of code, you might ask, "This seems to do X, and it does X for this reason, right?"

Handling it with small talk like this is also good. It might be better than several lines of text-based conversation.

Principle 2, simply put: a whiteboard and face-to-face conversation are more efficient than complex and fancy collaboration tools.

Ultimately, what I want to say is: simplicity is the ultimate sophistication. This is truly real.

Now, I will explain the third principle.

First, remember this number well: 80!

When I develop, my preferred approach is to consistently produce 80-point code and maintain its quality, rather than intermittently spitting out 100-point code. I believe that makes a good developer.

The point here isn't about developers who have no intention of improving beyond 80 points. Let's look at an example.

Let's examine a business logic here. We have table A, and table A has been migrated to A_new.

The logic has also been rewritten. However, for a friend with A ID 123, the structure is so broken that A_new cannot be used, so we want to use the logic that directly uses A for friend 123.

What should we do? Migrating friend A to A_new could take a lot of resources and a long time. Let's say it takes about two weeks.

Let's assume both old and new structure logic exist, and that A's data has a constraint of no longer being used and expiring in a month. And let's say we have to launch tomorrow.

So, how do we solve this problem? It's simple, right? We deploy this code along with it.

if(a.id == 123) {
  구구조 로직(a.id)
} else {
  신구조 로직(a.id)
}

Adding just this one line seems like it would work, right? Is this a bad idea? It would probably be better to compromise like this and then follow up on issues arising from the new structure.

Alternatively, it's not like we can awaken some transcendent divine power and demand that a two-week migration be completed in a single day.

This is compromise. However, it can be a double-edged sword. Compromise always boasts magical efficiency when the situation we've assumed is 100% satisfied.

But the moment that premise breaks, it's the beginning of hell. Let's say unmigratable data like 132, 111, 192 keeps being detected. And the premise arises that it could happen again in the future.

We clearly wrote such code under the assumption that only 123 would be incompatible and that it wouldn't happen again in the future. However, as that premise ultimately broke, this compromise led to inefficiency.

Here, we need to decide whether compromise is necessary or if we must complete all missions. And by compromising, we should allocate the saved resources to other missions.

Therefore, compromise is not always necessary, yet it is also necessary. Please use this small key wisely. An 80-point code with appropriate compromise is good.

Don't over-abstract to write 100-point code. Abstraction isn't about eliminating complexity; it's about hiding complexity in a deep abyss.

Some people like the phrase "This is clean," but what does that matter? Instead of spending more time on that, just use a linter. It's better to focus your attention elsewhere.

This is my development philosophy: maintain 80-point code through optimal decision-making and appropriate compromise. This is my final principle.

This friend, compromise, will be used a lot not only in code but also in other product development. It's good to acknowledge a concept and write an equation for it, but

it's also good to simply compromise and define it as a constant, then write the formula. However, from a fundamentalist perspective, it would be more reassuring to express that constant as a formula as well.

Anyway, compromise will eventually need to be eliminated, but it's good for temporary solutions. Don't worry too much; what's wrong with it being a little messy?

Isn't it similar to life? I think not being too perfect is charming and even cooler.

Carpe diem #

Alright. The boring talk is over, right? Now let's move on to the Carpe diem session.

Do you happen to know what Carpe diem means? Many of you probably do: "Seize the day."

In other words, do what makes your heart race. Do what you want to do. Don't live stifled, don't avoid things. It's very cool, isn't it?

Everyone, for this moment, let's temporarily step away from development and job hunting. It's free time~

As you listened to the presentation above, you probably felt different things. Some received great motivation,

while others, though motivated, might feel they haven't achieved much and, even knowing all this, wonder what to start with, or feel overwhelmed by too many things to do.

Yes, none of that matters. For now, let's cast aside those worries.

I hope that as you go through life, you don't pursue paths like "If you do this, they say you'll get a lot of money..." or "It's not fun, but you can make a living..."

Although you've become Meister High School students as engineers, I hope you also become artists. Even if you're serious about technical things, I hope you cultivate an artistic sense,

and I hope you live without knowing the word "impossible." Even if you think something is impossible, I hope you identify it as "conditionally impossible" and strive to meet those conditions.

How can you do that? Typically, I think living with innovation as a life value would be quite helpful.

It depends on how you define it, but for me, innovation is:

I believe innovation is the result of high-level technical engineering and art that breaks free from convention. And I believe innovation is accompanied by our fundamental self-realization and significant wealth.

The effects of combining art and technology have already been proven many times.

Consider the iPhone. It combined high-level technical engineering with design that maximized user experience, changing the world. And did Steve Jobs have little money? No, he had an insane amount.

Let's look at Elon Musk. SpaceX, SolarCity, Tesla, OpenAI, and so on.

His technical capabilities are outstanding, and his artistic idea of producing all components himself to cut costs, combined with his drive to create, led to remarkable innovation. Does Elon Musk have little money? LOL.

Of course, I'm not saying you must become Elon Musk or Steve Jobs, but thinking is something we can do, isn't it?

Rather than "I want to get a job at OpenAI," how about "How can I build a company bigger than OpenAI? What is OpenAI's fundamental corporate value? What kind of culture do they have, and how do people work there?"

You can learn. If you ask many questions, motivation will naturally arise. However, this motivation only comes when the questions are genuinely what you desire, activating the reward and hope circuits in your brain.

But... I understand all that, so what should I do? I'll give you a simple warm-up for this question, something artistic that will make your heart race.

First, try making art with yourself as the subject. Create a nickname, design a logo. It's like "look-ddal" (dressing up for looks) in self-branding.

Here's a little break to tell you the origin story of my nickname and logo.

I originally went by Khope. Simply because my name was Kim Heemang (희망 means hope).

Then one day, Khope didn't look aesthetically pleasing to me in English. So I removed the dash and changed the 'k' to an 'r'.

And I colored this 'r' red. The logo created that way is this:

If you look closely at this logo, it looks like "la" instead of "h." So I was inspired by this.

I changed my ID from rhope to rlaope. Now, do you know what appears if you press the Korean/English key and type "김" (Kim) in Korean?

It shows "rla." And "la" has the shape of an "h." That's how my nickname and logo, meaning "Kim Hope," were created.

I think it's very well-made, and I'm personally satisfied with it. Now, everyone, don't these kinds of artistic activities make your heart race?

You don't necessarily need to create something new or adorn someone else's things when doing something artistic. Let's start by cultivating ourselves with this kind of art. Then you'll get the hang of it.

And what makes our hearts race is art. The very act of creating something, I believe, is an activity that breaks free from existing frameworks.

I mentioned earlier that I'd answer the questions "How do I gain individuality?" and "How do I take the fast lane?" The answer is this:

ART. It's not limited to design. Art exists in all forms, whether intangible or tangible. It can be a combination of different fields, or it can be imitation.

In other words, it could easily be said as "let's cultivate many alter egos."

However, there are sometimes eccentrics who find the technical operation of machines artistic. Yes, they have good capabilities as engineers, and it seems they don't need to unnecessarily seek out other things.

Since I experience the combination of art and technology I pursue entirely through computers, you could say it's my aptitude. They're the ones who take the fast lane just by touching computers. You're not, you say?

So what? Art isn't just one thing; it can be combined with other fields. Those other fields could be finance, fashion, broadcasting, writing, or even food.

It could be games, or animation. Among so many disciplines and topics, do you think there's nothing for you? Really? There's definitely at least one.

But what if you have absolutely none of these? No hobbies, and you just live a restful, stable life... Yes, the keywords are out: stable, restful.

What's stable and restful? Buildings? Stocks? Maybe an ETF that consistently pays dividends. So, what's the plan to achieve that?

Listen to the voice of your heart. If there's something you can't do right now, find the reason why. If you have debts, which is rare for students, then think about how to pay them off.

I hope you live a life where your desires and freedom are not suppressed.

You have the power to achieve anything if you desire it, ponder it, and solve it.

You are geniuses. Do you think you're too stupid to do anything on your own?

The reason Einstein was able to prove the theory of relativity wasn't because he was a genius with inherently faster computational speed than others, but rather

I believe it's because he computed more than anyone else and pondered the theory of relativity longer than anyone else, which made him the fastest and best at it. So, more input than us means more output.

Humans can grow, and they are animals designed that way. I don't know why, but humans are surprisingly foolish yet also intelligent. The possibilities are endless.

I really dislike the word "impossible." Whether at work or in a club, if a team member says "it's impossible" without attaching conditions, just "it can't be done,"

I get angry. "It can't be done due to lack of time." This kind of reason prompts me to ask for specific evidence. If we have 2 hours of work time per day, and considering build and deployment time, we allocate 1 hour,

and even if we assume we can work 7 hours a week, or even 14 hours if we push it, this task is impossible because it takes 20 hours. If it's explained like that, it's okay.

Then the possibility of solving it through other methods is left open, isn't it? But "I can't do it. I'm too stupid to understand."

Why can't you understand? What part don't you know? All of it? If it's "all of it," isn't that an easier answer to identify the problem than "I don't know what"? It means we have to start from the beginning.

Nothing is impossible. You are full of potential. I was, and so was everyone else. You need to do what makes your heart race to invest a lot of time.

The more time you invest, the greater your value becomes. As your value grows, wealth and capability follow, and you can live a recognized and satisfied life.

Will you live an empty life without dreams, or will you Carpe diem?

This concludes my presentation. Thank you!

Q&A #