DEV Community: BJ Kim

That Small Obsession

BJ Kim — Tue, 01 Sep 2026 07:05:23 +0000

Honestly, I've had a lot on my mind lately. The ways of working I spent years learning, practicing, and relying on feel like they're crumbling all at once. Some days I can barely find the joy in the work.

Design and frontend can now be built in a few prompts, so these days I find myself starting from a finished, working screen the AI has already drawn — interface and all — and building from there.

In code reviews, when I ask why a certain feature exists, what it's for, who it serves, the answer is often "I don't know."
Where are we actually headed? Is it enough to just build what was asked, on time?

There's a trap in drawing the screen first. Once the screen appears, it starts to look like the answer itself. And naturally, the back-and-forth disappears.
What problem were we trying to solve? What do we actually need, and where should we sweat the details?
"Do we even need this feature?"
"What are the other options?"
"Is this the right place for it?"
Because the result lands in our hands so quickly, the space where that thinking should have happened gets hollowed out entirely. I'm watching it happen.

The approach is "build fast, fix later" — but for that to work, you have to stop and look back at least once.
Only then do the things that need fixing become visible, the things that can be removed become visible, and you can judge whether this is even the right screen for the problem.

Everyone builds easily and quickly now. Building fast has become the baseline.
It feels like we're crossing into a time when we have to ask again what real competitiveness even is.
Because we'll keep bolting on the more complex, more numerous features that AI proposes — and if we can't explain why a feature belongs there, and why it was built that way, that would be genuinely embarrassing for someone who makes products.

The edge for the people who build products, going forward, might come down to the eye for removing 9 of the 10 features AI suggests and finding the 1 that truly matters.
Yes — in the second half of 2026, it's not about adding fast with AI, but about taking away. I think we've reached the moment when that matters.
Miss this, and we'll be building screens and features that somehow work but that no one understands — and in the end, all that's left is something that solves nothing. It gives me an uneasy, almost frightening feeling.

Back in the early days of app development, there's a well-known story about a thread-long argument over whether the hamburger button — the full menu, the "more" button — belonged in the top-left or the top-right. You could call it a kind of romance.
But before you do, don't forget: it was a wonderful episode born of a stubborn need to nail the smallest detail — which position would be easier for the user to tap.
I hope we'll ask ourselves whether that stubbornness is quietly slipping away from us.
Building fast is something AI now does far better than we do. Deciding what not to build, on the other hand, should still be ours. Looking hard at what AI built so quickly and asking why it should exist, whether this is the right place for it —
in this moment when making things has become so common, maybe that single question is what gives us our reason to be.

When an Organization Changes Shape, So Should the Way It Communicates

BJ Kim — Tue, 01 Sep 2026 06:40:02 +0000

When an organization wants to move faster, the first thing it usually reaches for is structure. It breaks big teams into small ones, and regroups people who were organized around functions into teams organized around purpose. The expectation is that making things smaller and lighter will make them faster.

And yet, we often hear that even after changing the structure, things move just as slowly as before—sometimes even slower. The reason is surprisingly simple. The structure changed, but the way people work within it—how they communicate, who is responsible for what, how far they can decide on their own—stayed exactly the same.

When the structure changes, at least three things need to change along with it.

First, communication. If you've broken teams into smaller units, communication should get smaller too. If you still route work that could be settled by talking directly to the team next door up through the hierarchy and back down again, the seats got closer but the road got longer. If the habit of gathering everything upward and then handing it back down stays the same, splitting the teams loses its meaning.

Next, roles and responsibilities. A new structure needs new boundaries. If you lay the old structure's lines of responsibility directly on top of the new teams, gray zones appear—"Wait, whose job is this?" And work that belongs to no one ends up getting done by no one.

Last is authority, and honestly, this is the one most often left out. If decision-making power stays up top as before while only execution flows downward, the small team has to climb back up for permission every time it wants to decide something. The team built to be fast ends up standing still the longest, waiting on a single decision.

In the end, changing the structure is only the beginning. Just as changing the bowl means changing how you serve, changing the structure means the ways of communicating, the lines of responsibility, and the location of authority all have to move with it. Otherwise you're left in an awkward state—new in shape, but old in how the work actually gets done.

Is your organization, perhaps, drawing up a new structure while leaving everything else as it was? Maybe the reason things aren't getting faster isn't that the structure is wrong, but that only the structure changed.

And this isn't something that plays out only on the org chart. In the end, it comes down to each person's day. Think back on what you did today. Was it something you raised because you wanted to? Something the team agreed to take on together? Or something that was decided somewhere and handed down to you? Are you walking alongside the person who first proposed it—or were you simply handed the work and left to wander on your own?

If these questions are hard to answer right away, it may mean that the work flowed to you, but the reasons it began and the people you're meant to do it with didn't flow with it. When decisions come down but context doesn't come with them, a person can be clearly working and still be lost. Maybe a structure working well isn't something grand at all—it's simply a state where each person can answer these questions clearly.

The Weight of a Piece of Meat on the Table

BJ Kim — Tue, 01 Sep 2026 06:39:46 +0000

I recently watched an interview in which a documentary producer who films the remote corners of the world talked about the Hadza of Tanzania — said to be the last hunter-gatherer people left on Earth. They don't farm, and they keep no livestock. They hunt, and when the hunt fails, they dig up roots and gather berries. They have no private property, so whatever they catch is shared equally by everyone. Their houses are loosely woven from branches, and when the game moves on, they leave the houses behind without a second thought and move on too.

The producer spent several days living exactly as they did, eating and sleeping alongside them — including sharing the meat of a monkey they had hunted. A single piece of meat that reaches the mouth only at the end of the whole process: chasing, killing, getting blood on your hands, butchering, dividing. Under the video, someone left a comment: "Primitive."

But the producer's answer stayed with me. We don't buy meat at the supermarket because we're civilized, he said — we do it because our jobs are divided. Someone raises the animal, someone slaughters it, someone packages it, and we hand over money and receive it. They simply do all of it themselves, all at once. It isn't a difference between civilization and savagery. It's the difference between splitting the process among strangers and living through all of it yourself.

I'm not saying the division of labor is wrong. It may be one of civilization's greatest achievements — it's what lets each of us go deep on our own work. But the convenience came at a price: we now receive meat with the process of death erased from it. Between people who take their food while living through life and death in full, and people who consume meat with death wiped away, paying money instead — which side truly knows the weight of life? That was the producer's question. I couldn't easily pick an answer.

And lately, this story keeps overlapping with my work.

We live in an era when AI draws our screens, writes our code, and finishes our documents. More and more, we find ourselves seated where results arrive without process — like supermarket meat, with everything that came before erased. I'm no exception. I ask for something, and if I don't like the result, I regenerate it without even reading it. Again and again. Something that once took days of agonizing to make now takes less than a second to throw away. It's convenient, and honestly, I like it. But sometimes I get the feeling of being full without knowing what I ate.

What remains for humans in the AI era? Lately, the English-speaking world keeps answering that question with one word: taste. In Korean we might call it gam — a feel for things — or anmok, an eye for quality. The ability to tell the difference between what looks right and what is right. The ability to sense that something is off before you can explain why. A Hadza hunter can read a track at a glance, they say — how old it is, whether it's worth pursuing. That feel isn't innate. It's what hundreds of failed hunts leave behind in the body. Taste is a byproduct of process, not of results, which is why no amount of received output will produce it. The plausible is now in infinite supply; the eye that separates plausible from good is still made only the old way.

That's why I believe this difference will not go away: between someone who knows even one thing deeply, who has passed through the whole context with their own body, and someone who just receives results and likes them. How that difference gets used varies by organization, of course. And living through every process yourself is as unrealistic as returning to a world before the division of labor. Some seats need depth; others need speed. We've reached a point where you can't even call one side right and the other wrong. Still, one thing seems clear. If you give away the whole process and let go of taste too, the only role left is to receive results and say they look good — and machines already do that faster than we do. Losing your taste isn't when replacement begins. It's when the last thing standing between you and replacement disappears.

There's one more scene that bothers me: a table where we keep ordering even though we're full, and throw away the meat we leave behind.

Because making feels free, we make in bulk — screens that may never be used, documents no one will read, code no one will review. Like the outputs I discarded without reading. The English-speaking world has started calling this flood of output "slop" — the word for pig swill. But it isn't free. Every generation spends tokens; tokens come from data centers, data centers run on electricity, and electricity, in the end, comes from somewhere on this planet. Just as moving the slaughterhouse out of sight erased death from our meat, the data center being out of sight has merely erased the cost of generation. The Hadza hunt only what they need and share everything without waste — not out of superior discipline, I suspect, but because they know in their bodies what a piece of meat costs. No one wastes out of malice. Wherever the price is out of sight, anyone will.

One scene from the producer's account refuses to fade. The Hadza are not a warlike people; disliking fights over land, they kept yielding, and have been pushed further and further from hunting grounds they lived on for thousands of years. Some now make a living performing mock hunts for tourists. And this: while hunting, their eyes blaze as if to say, "I am still alive" — but at rest, having lost their hunting grounds, those same eyes turn sad. It seems that what a person stripped of their process loses isn't just a dulled sense. Perhaps the same thing is quietly happening to us, as we trade away our process one handspan at a time for convenience. Replacement may begin in the eyes long before it arrives as notice.

We can't hunt all our own meat. We don't need to, and I'm not saying we should go back — once civilization comes in, they say, there's no holding it back. But we can choose how we sit at the table: as a hunter, not a receiver. A hunter isn't someone who is handed meat — a hunter is someone who decides for themselves which track to follow. So live through the one thing at the center of your craft from start to finish, and before asking for anything, turn the questions back toward yourself. Can this actually be eaten? What is it that I should be making right now? Is it worth making at all? Producing what we're handed, quickly, is something machines already do better. But deciding what to make, and whether it truly matters, still belongs to us. And that is why I find myself hopeful. Hunting tools have never been this good, which means there has never been a better era for a hunter who knows what to chase. The eyes that say "I am still alive" light up the moment you choose what to hunt.

What Is Love?

BJ Kim — Tue, 01 Sep 2026 06:26:36 +0000

On my way home from work recently, a thought suddenly came to me. What did I do for someone today? I did code reviews, listened to a junior's concerns, and bought the bread my wife likes on the way home. And I came to think that each of those things was ultimately love.

When people hear the word love, most think of the feelings between lovers. That passionate emotion depicted in movies and dramas. But having worked for nearly 20 years and been married for over 10, I've come to think that love isn't something so grand.

I want to define love like this: willingly spending time for someone else.

Think about it—there's no resource as equal yet finite as time. Everyone has 24 hours in a day, and that time doesn't come back. Spending such precious time on someone—isn't that the most honest expression of love?

When a junior at work comes to me stuck on something, honestly, sometimes it's bothersome. I have my own work to do. But going beyond that annoyance to think together for 30 minutes or an hour—that's love for colleagues, I think. I'm not just saying something from a book somewhere. It's really true.

It's the same with my wife. Early in our marriage, I thought I needed to do grand events for every anniversary. Expensive restaurants, surprise gifts, those kinds of things. But 10 years later, what my wife really appreciates isn't that. Going for walks together even when tired after work, making a cup of coffee on weekend mornings, listening to her talk until the end. Ultimately, it was spending time together.

Of course, just spending time doesn't automatically become love. If you're reluctantly sitting next to someone while looking at your phone, that's not spending time. I think real love is being completely present with the other person during that time. Making eye contact, listening to their words, responding.

Love for work is the same context. As a developer, spending hours thinking about how to write good code, reading books and studying for better design—isn't that also a kind of love? If you were only working for money, that time wouldn't become so serious.

But there's something important here: love means giving before receiving.

When I was young, I wanted to be loved. I wanted someone to recognize me, acknowledge me, like me. But as I age, I realize: it's much more comfortable to give love first than to wait to be loved. If you expect, you're bound to be disappointed, and disappointment tends to sour relationships.

It's the same at work. If you work to be recognized, you tire quickly. If you don't get promoted or your performance isn't properly evaluated, resentment builds. But if you work because you want to help colleagues, because you want to make the team better, that itself becomes rewarding. Of course, getting recognition too would be even better.

Looking back, my happiest moments were mostly when I gave something to someone. When a junior solved a problem with my help, when my wife smiles at something small I did for her, when my child hugs me saying it was fun playing together. Those moments accumulate to make life rich.

Love is ultimately the time invested in relationships, being completely present with the other person during that time, and starting by giving rather than receiving, I think.

It doesn't need to be grand. Offering a cup of coffee to a colleague next to you today, making a phone call to check on family—those small things gather to become love. I hope your day today is filled with such small loves.

What Failure Taught Me

BJ Kim — Tue, 01 Sep 2026 06:26:03 +0000

Have you ever seen someone say "I tried this and it didn't work out" in a meeting?

I haven't seen it often. In most meetings, success stories are shared and successful projects get the spotlight. Stories of failure are quietly buried or never brought up at all. Honest talk only comes out in anonymous surveys, and few people are willing to attach their name to failure.

Why is that? Fear of looking incompetent. Worry about disadvantages for future opportunities. Concern about others' perceptions. The reasons vary, but the result is the same. Failure becomes something to hide, and we lose the opportunity to learn from it.

What Happens When We Avoid Failure

When we fear failure, we reduce our attempts altogether.

We try to do only what's certain. Proven methods, things others have done, things with low probability of failure. This feels safe in the short term. But in the long run, growth stops. Without new attempts, there's no new learning.

The same applies at the organizational level. In cultures that hide failure, the same mistakes repeat. Team B experiences the exact same failure that Team A had, without knowing about it. Individual failures never become organizational assets, and everyone pays the same tuition separately.

And most importantly, in organizations where failure isn't discussed, success stories aren't trusted either. "Has this person never failed?" becomes a question, and shared success stories feel like edited highlights.

What Only Failure Can Teach

Looking back, I've failed so many times. At the time, I didn't even realize they were failures.

When a project I'd worked on for six months was scrapped right before launch, I thought "the timing just wasn't right." When an architecture I'd pushed confidently required complete redesign after three months, I rationalized it as "requirements changed." I said hurtful things to team members and only realized much later. When a hiring decision went wrong and the whole team suffered, I thought "just bad luck."

Now I see them all as failures. And most of what I truly learned came from there.

When I succeeded, I thought "I knew my judgment was right" and moved on. I didn't deeply analyze why it succeeded. I didn't distinguish whether it was luck, skill, or timing. It worked, so I just thought it worked.

But when I failed, it was different. I had no choice but to think "why didn't it work?" I had to consider where my judgment was wrong, what I missed, what I should do differently next time. In that process, I came to understand more deeply about myself, about work, about people.

Failure teaches humility. You learn through experience that you can be wrong, that your convictions aren't always right. Without this humility, it's hard to accept feedback, and without accepting feedback, growth stops.

Failure builds resilience. Someone who has fallen hard once knows they can get back up when they fall again. Someone who has never fallen crumbles at small failures. Failure muscles can only be built through failure.

What Incident Reports Tell Us

We've had a lot of incidents lately. Honestly, I've written quite a few incident reports.

After 20 years of development, I've learned something. When code production and change volume go up, the probability of incidents increases too. It's obvious. If you don't touch anything, there are no incidents. If you don't release new features, don't improve the system, don't take risks, incidents don't happen.

So having many incidents also means we're trying, building, and creating that much.

Of course, fewer incidents is better. They inconvenience users and stress the team. But I think it's better to try, fail, and learn than to attempt nothing just to avoid incidents.

Every time we write an incident report, we learn. What went wrong, why it happened, how to prevent it next time. As that learning accumulates, our service becomes more robust, and our developers grow directly and indirectly. A developer who has experienced incidents is definitely different from one who hasn't.

There's no need to be ashamed of incident reports. They're actually records showing how much we're trying and how much we're learning in the process.

The Courage to Talk About Failure

Of course, you don't need to publicly share every failure. Failure has context and timing. Bringing it up before the wound heals is hard on yourself too.

But at the very least, I hope you won't be ashamed of failure.

Having failed means you tried. Those who don't try don't even get the chance to fail. Having many failures also means you've challenged yourself that many times.

I sometimes ask in interviews, "What's your biggest failure experience?" Some answer "I've never failed." That might be true. But I worry a little. Did they really never fail, or can they not recognize failure as failure, or do they think admitting failure is disadvantageous?

I actually trust more the person who says "I failed at this, and this is what I learned." It means they can view their experience objectively, and they know how to learn from it.

The Prison of Others' Perceptions

We're more conscious of others' opinions than we think.

"What will they think if I say this?" "What if I get labeled as a failure?" "What if I don't get opportunities later?"

These worries make us quiet. Make us safe. And eventually, make us small.

But honestly, others aren't that interested in our failures. They're busy with their own work. Almost no one remembers the failure we had a year ago. The only one who remembers is ourselves.

Not trying because of others' perceptions, hiding failure, only talking about success. When these things accumulate, we gradually start living a fake version of ourselves. Like an SNS account that only shows edited highlights.

If you're afraid to show the real you, it's worth examining what that fear actually is. Most of the time, it's fear inflated beyond reality.

How to Turn Failure into an Asset

Failure itself isn't an asset. It becomes an asset only when you learn from failure and apply that learning next time.

So when I fail, I ask myself a few things.

What went wrong. Where was my judgment wrong. What would I do differently if the same situation came up. What did I learn from this failure.

If I can answer these questions, that failure has already become an asset. If I can't answer them, I'm likely to repeat the same failure.

And if possible, I share that learning with someone. With juniors, with colleagues, or like this in writing. If my failure can reduce someone else's trial and error, that failure gains greater value.

In the End, Failure is a Byproduct of Trying

It would be nice to succeed without failure, but reality isn't like that.

If you try something new, you might fail. If you challenge a difficult problem, you might fail. If you try to exceed your limits, you might fail. That's normal.

Having no failure means one of two things. Either you're really lucky, or you haven't challenged yourself enough.

I will continue to fail. And I will learn from those failures. That's the surest path to growth I know.

When was your last failure? And what did you learn from it?

The Essence of Vibe Coding

BJ Kim — Tue, 01 Sep 2026 06:26:00 +0000

Working on plabOS lately, there's one thing I've become absolutely certain of. Projects rarely fall apart because AI can't write code well. Even if there are shortcomings, today's loop-back structures and iterative improvements can compensate adequately.

Yet there are still moments when projects start to wobble. Most of these occur when people fail to properly read what AI has produced.

The Problem Isn't Generation—It's Neglect

The typical flow of vibe coding looks like this: write a prompt, get code, run it immediately, get an error, paste the error message back in.

Repeat this loop a few times, and at some point, nobody can explain "why it's not working." Code keeps getting added, but not a single line of understanding has accumulated.

This isn't a simple mistake. It's a new anti-pattern of the AI era. Generation speed has increased, but comprehension speed hasn't kept up. When this gap accumulates, projects quietly collapse.

In the past, the bottleneck was how fast you could write code. Now, the bottleneck is how fast you can understand code. Yet many teams are still focused only on generation speed. It's like only caring about how fast you're pouring water, without checking if the container has holes.

The Clear Difference Between Projects

The difference between projects with few bugs and those with many is surprisingly simple. It comes down to whether these three things were actually "read and understood":

First, did you carefully read the planning documents AI created? Second, can you visualize the folder structure AI organized in your head? Third, do you understand the DB schema AI proposed?

Just following these three things cuts bugs in half, whether you're using AI or not. Because most problems arise not from "building it wrong" but from "modifying without understanding the context."

AI quickly proposes structures. But interpreting those structures to fit your organization's context is still a human responsibility. The most stable projects I've seen weren't stable because the AI was exceptional—they were stable because team members fully digested AI's proposals before moving forward.

The Illusion of "It'll Figure It Out"

I went through the same process myself.

"AI will handle this much." "Let's just get it running and look at it later."

The results were always the same. Code that collapses entirely with the slightest modification. Directory structures with complex hierarchies. Ultimately, time spent reading everything from scratch again.

That's when I realized: time saved by skipping reading doesn't disappear. It always returns as a larger cost.

This isn't a development problem—it's a decision-making problem. It's the choice between "reading for 30 minutes now" or "debugging for 3 hours later." And most of the time, we choose the 3 hours later. Because the 30 minutes right in front of us feels more precious.

Now 'Interpreters' Matter More Than 'Writers'

Many people say, "The era of writing code yourself is over."

I'd put it this way: the time spent writing code has decreased. But the time spent reading and judging code has become far more important.

Looking at AI-generated code, we need to make judgments. Does this structure fit the current business model? Is this design scalable? Can the next person understand it?

Simple bugs can be fixed through automation. But structural errors don't resolve automatically. When a service that was running normally suddenly experiences an unexplainable failure, the responsibility ultimately falls on humans. You can't blame AI then.

There's a certain nuance to the term "vibe coding." By feel, roughly, quickly. But when I look at people who are actually good at vibe coding, they read more carefully, not less. They grasp the intent behind AI-generated code, adjust it to fit the context, and request a complete redo if necessary. It's not that their intuition is good—their reading comprehension is good.

The Culture We Need to Build First

Before learning how to write better prompts, there's a culture I want to establish first:

"Read first, then execute."

Don't skip planning documents. Only modify when you can explain the folder structure. DB changes are made by people who understand the schema.

This approach may seem slow at first. But in the long run, it's the fastest path. Because this approach doesn't depend on any particular developer's intuition. A process where anyone can reach the same conclusion. I believe that's the condition for a scalable organization.

As AI advances, the developer's role shifts from "the person who builds more" to "the person who understands to the end."

Why This Matters for Non-Developers Too

This isn't just a story for developers. It applies equally to planners, operators, and PMs who use AI tools.

Organizations that execute AI's output as-is appear fast, but their maintenance costs eventually explode. Conversely, organizations with a culture of reading, understanding, and verifying results achieve both speed and stability.

Whether AI or a human wrote the planning document, if you don't read it properly, the result is the same. The moment someone says "that was in the document" during a meeting, a reading failure has already occurred.

Conclusion

The core of vibe coding isn't intuition. It isn't input skills. It's reading comprehension.

The moment you skip reading, AI stops being a productivity tool and becomes a chaos amplifier.

The opportunity for developers going forward isn't in making people use AI more—it's in the process of ensuring organizations understand AI's output to the very end.

How much is your team actually reading AI's output?

The Courage to Find Yourself

BJ Kim — Tue, 01 Sep 2026 06:25:28 +0000

I've always believed that a team leader's role isn't to decide the path for others, but to help them in the process of finding their own. I still think this way, and I've been making decisions and acting on this belief for nearly 10 years.

It hasn't been an easy path, and there have been many trials and errors along the way. But looking back, I think I've done reasonably well—maybe about 51% successful. It's gratifying to see people finding their own paths, yet I also feel for them, knowing the difficulties and confusion that come with the journey.

One of the Hardest Things in the World

Having lived a while, I've come to realize that one of the hardest things in the world is the process of finding yourself.

What do I like? What makes me happy? When does time fly the fastest? This process of "self-learning" is what I'm talking about. Through time spent observing and learning about ourselves, we gradually come to understand ourselves more deeply.

I believe that anyone can achieve complete immersion when doing what they truly love, and that immersion leads to outstanding results that others find hard to match. These are results that can never come from forced work.

However, walking this path requires the courage to become somewhat free from others' perspectives and social standards. The path your parents want, the path others call stable, the path that earns envy—distancing yourself from these and establishing your own standards requires more courage than you might think.

Choices Made Without Exploration

In our educational environment that makes creative expression difficult, this kind of exploration isn't easy. We've been trained countless times to find the right answer, but we've never been trained to ask our own questions. We learned what makes a good university, what makes a good company, but we had to find for ourselves what makes a good life for us.

However, choices made without the process of finding yourself ultimately reduce the sustainability of success. It's hard to persist on a path chosen by someone else's standards. Because there's no reason to endure when things get tough. On the other hand, on a path you've chosen yourself, you can find meaning even when it's hard.

Only a courageous few choose this path and walk it to the end. I hope those reading this will be among that few.

Risk Management in an Era Without Right Answers

In an era without clear answers, I believe establishing your own standards is the most powerful form of risk management.

In the past, the formula of good university, good company, stable job worked to some extent. But now that formula is shaking. AI has emerged, industrial structures are changing, and the concept of lifelong employment is disappearing. In such times, moving according to others' standards is actually a risk.

People with their own standards aren't shaken by change. Because even when the external environment changes, they know the direction they want. On the other hand, people who've lived by others' standards lose direction the moment those standards collapse.

Whose voice are you listening to today?

Nevertheless

The truth is, we can't always live doing only what we want. Sometimes we face the limits of our talents, and sometimes we hit the wall of survival. What we love might not make money, and we might not be good at what we want to excel at.

That's why this path requires even greater courage. Not giving up on observing yourself, even if you're currently in a place you don't want to be. Continuing to explore what you want, even if you can't do what you want to do right now. I think that could be the weapon that helps us survive in this era of dramatic change.

Watching Black and White Chef

Watching Black and White Chef recently, I realized something.

When you reach the stage where you've done sufficient self-exploration and immersed yourself in a field you love, whether someone is better or worse becomes completely irrelevant. Looking at the chefs who made it to the finals, what stood out wasn't the difference in skill but each person's unique color. It seemed almost meaningless to determine who was objectively superior.

At that stage, I felt that narrative becomes more important. Why did you start cooking this way? What journey brought you here? What story is contained in this dish? And this realm requires more than just effort-based skill. The element of luck is also necessary.

Ultimately, what we can do is build our skills while creating our own narrative. We can't control luck, but we can prepare.

I think the journey of finding yourself might be the beginning of that preparation.

Master Your Time

BJ Kim — Tue, 01 Sep 2026 06:25:25 +0000

I watched that Running Man episode so enjoyably that it suddenly came to mind and made me write. Nothing more.

I'm just going to write about how I tried this and it worked for me.

By nature, I've never been early anywhere.

School, academy, appointments, even the military (huh?!)

But there's one life pattern I picked up and made into a habit through a superior (who might appear occasionally?) I met at my previous company who taught me many things.

Arriving at work earlier than the scheduled time!

That's the medicine I'm selling today.

'Why does that person come in an hour early?'

'No way, they only sleep 3-4 hours a day?'

'Today the bag is here but the person isn't?'

'Where are they and what are they doing?'

We only worked together for a year, so it's more regrettable but perhaps that's why it struck me so intensely.

One day, I suddenly went to that empty seat after they left, and for some reason, the competitive spirit arose that I should try this too.

Since then, I try to come at least an hour early, or at minimum 30 minutes early, almost every day.

No, anyone who works should do this.

What's good about coming to work early?

You Gain Margin

This is the biggest reason. Obvious, but not obvious.

If you come early and start working, it loses its meaning.

For example, if I come an hour early, I spend about 10 minutes preparing coffee and snacks, about 30 minutes reading a chapter of a book or studying English, about 10 minutes spacing out, and the remaining 10 minutes checking emails that came overnight while scheduling my day's work before joining the standup meeting.

When I come 30 minutes early, even if I skip one or two things, I always spend 10 minutes checking work before entering work hours.

What's the difference?

There's a famous quote from Baemin's CEO Bongjin Kim:

"9:01 is not 9:00."

It's a phrase that contains many things depending on how you think about it.

I've witnessed multiple times that people who don't keep the basics have no opportunities and lower their own value.

Your Expression Brightens

Interestingly, when you have margin, your expression brightens as a positive cycle. Because your day is organized in your head, you're confident and assured when anyone asks. That stance naturally affects interpersonal relationships.

Think about it. How good can the expression be of someone who was just crammed in the subway from hell, ran in breathlessly to avoid being late, and joined the standup catching their breath? And what about the people watching such a colleague?

Considering that half of most company work is relationships and communication with people, by coming in a bit early, you've already crossed the threshold, haven't you?

Today's meetings at what times, lunch appointments with whom—these things get reminded and you become less scattered. You can focus during meeting times too. Ultimately, these small things one by one naturally come across as trust to colleagues.

There's a Higher Probability of High Daily Satisfaction

Same context. As troubles in relationships with people decrease, so do chances of getting red-faced or stressed.

Not only that, by grasping the day's work intensity efficiently before starting, you know in advance when you'll catch your breath, enabling appropriate energy distribution and time management. Through this, you come to physically learn about your concentration, work capacity, and yourself.

I didn't plan to write long, but it got rambly.

The conclusion is that time is equally given to everyone, but how you greet it can completely change the feeling.

Just try it for one week.

How long will you keep having a boring, annoying, bewildering company life?

Arriving at work earlier than the scheduled time!

Try this medicine once,

And become someone who leads your precious time.

In that process, new routines, communication, and processes will emerge.

That Small Obsession

BJ Kim — Tue, 09 Jun 2026 09:50:14 +0000

Design and frontend can now be built in a few prompts, so these days I find myself starting from a finished, working screen the AI has already drawn — interface and all — and building from there.

Between Delegation and Hands-On Leadership

BJ Kim — Thu, 05 Feb 2026 14:55:58 +0000

As I assigned a task to a junior colleague, questions flooded my mind. Should I step back and let them handle it, or should I stay closely involved? This decision turned out to be harder than I expected. After leading various teams for about 10 years, I'd like to share my thoughts on how to choose between delegation and close collaboration.

Delegation Works When You Think Alike

The right time to delegate is when your thinking aligns with the other person's in the big picture. When this alignment exists, you can expect things to run smoothly without much friction.

But can two people really think the same way? I don't think that's possible. We're humans, not machines. We can never think identically—we can only make similar choices and express ourselves in similar ways.

That's why delegation works best when you entrust tasks to someone who makes judgments similar to yours. At least in the organizations I've managed, this has held true. When I delegated to people who shared my perspective, the results fell within expected bounds. When I didn't, both parties ended up struggling.

So how do you find such people?

Love Makes Us Alike

Have you ever heard the saying that people who love each other grow to resemble one another? It actually seems to be true. They become similar not just in personality and speech patterns, but even in appearance. This happens because they spend so much time facing each other, looking at each other, and talking. In fact, our vocal cords respond to the sounds we hear, our facial muscles mirror the expressions we see, and our hearts are moved by the emotions of those beside us.

Why am I bringing this up? Because the person who thinks and expresses themselves similarly to you might not be someone you need to find and recruit—they could become that way through your existing colleagues. Loving your colleagues, inspiring them, and being inspired by them in return. All of these interactions might be the process of cultivating people who share your sensibilities. In a way, this could be the key to helping people grow.

Of course, people's core nature doesn't change easily. But there are certainly aspects that can shift depending on circumstances. Isn't MBTI a good example? How boring would it be to live a 100-year life locked into one of just 16 personality types? There's nothing quite as thrilling as watching people change, grow, and be transformed.

What about the opposite scenario?

When Close Collaboration Is Necessary

With people who are truly different from you, you need more frequent and closer communication. Acknowledging that you and I are different—that's where it starts.

Here's an important point. As a leader, you can't surround yourself only with people similar to you. Rather, you must be able to embrace those who are different. Teams become stronger when people with diverse perspectives and capabilities come together. And embracing different people requires more communication, more attention, and more love. What you can convey to a similar person in one conversation might take ten conversations with someone different. This process might feel tedious, but I believe it's the burden a leader must bear.

If things begin without sufficient groundwork, both parties will struggle tremendously. This is because expectations exist. When baseline standards differ, personal values and perspectives can diverge sharply. Add a lack of communication to that, and expectations start being mistaken for given facts.

"Shouldn't someone at this level just figure it out?" "Shouldn't a team lead at least know what I'm working on?"

Rather than assigning blame, these situations arise because neither party successfully communicated their position to the other.

If a leader hastily delegates in such a relationship, it can lead to uncontrollable outcomes. I've seen cases where it devolved into outright neglect. The line between delegation and neglect is razor-thin. It depends on how much effort you've put into understanding the work.

So what constitutes sufficient effort?

Who Sets the Standard for Effort?

The absolute amount of effort shouldn't be measured by your own standards. The real measure is how much the other person trusts you. Only when your effort reaches and is felt by the other person will they begin to move—and that's when things truly start.

From a leader's perspective, delegating without this process is, in my view, neglect. No matter how well you understand the work, the perspective from the operational level can be entirely different. Even if you think you've communicated enough, if the other person doesn't feel that way, your effort is still insufficient.

This is why leaders who are too skilled at hands-on work can be dangerous in their own way. Because they understand the work so well, they tend to skip explanations, assume too many things are obvious, and that gap can feel frustrating to team members. Understanding the work and conveying that understanding effectively are two separate competencies.

Conversely, the process of effectively communicating what you do is equally important. I'm not saying to create work for work's sake, or to play politics. Instead of dwelling on "Why is my team lead asking me to do this?", try thinking "Why did they come to make this request?" Eventually, the reason will become clear. If it makes sense, do it. If it doesn't, exchange opinions or officially raise the issue. Silence is the worst approach.

In summary, what matters is whether there's an atmosphere where such conversations can happen without silence, and whether there's an environment where issues can be officially raised. Since this too falls under the leader's responsibility, the leader's role is significant throughout the entire process.

In the future, we may see a social culture where people work alone. For hands-on leaders, this could actually be an opportunity. They can fulfill an entire team's role by themselves. Not many people can work this way. Shouldn't companies create cultures and environments where such individuals can operate like special forces?

What, ultimately, is the endpoint of leadership? I believe it's creating a state where you can delegate 100%. People who share your sensibilities, people who are different but whom you've embraced and grown alongside, and people who are better than you. When you can appropriately distribute work among these various individuals and fully entrust it to them, only then can a leader begin to see the bigger picture. There's no right answer in the space between delegation and hands-on involvement. But continuously checking how well you understand the other person, and whether that understanding is being conveyed to them, while moving toward that endpoint—that's the standard I've found for myself.

Coding with AI

BJ Kim — Thu, 05 Feb 2026 14:55:02 +0000

The past year has been the most painful time in my 20 years of professional life. While leading the development team at Flap, I had to accept the decision not to backfill departing employees, and with the remaining resources, I had to cover not just BE and FE, but also SE, QA, and AI—all of it. Because I had never worked this way before, even accepting and adapting to it took all my energy, let alone understanding it.

Looking back at how the company came to make that decision, it ultimately came down to not keeping pace with the startup scene, which is feeling the impact of AI-driven changes across the IT industry first. Just as Stack Overflow's traffic has plummeted, countless business models that provided coding education are now facing a crisis. Because people are using AI to generate code directly.

Yet paradoxically, I myself am enjoying coding more than ever right now.

Rediscovering the Joy of Coding

For the past 10 years, I needed colleagues' help to properly implement the things that required development. There were certainly parts I couldn't handle alone. But now, I'm building and managing all of those things through AI. In the past, I would struggle all day solving difficult bugs and have no energy left to spend time with my wife after work. Now, thanks to AI as a pair programming partner, my mental fatigue has decreased significantly.

Before, when I got stuck on tasks like Stripe webhook integration, I would spend half a day digging through documentation, searching Stack Overflow, and asking colleagues. Now, I explain the context to AI, have a few exchanges, and most problems get solved. That time can now be spent on more important decision-making.

Of course, there's also the opposite experience. Lately, I'm realizing I need to use AI in moderation as I watch myself spending more time on development because of it. I thought better tools would mean less work, but instead, the things I can do have multiplied. Features I used to put off saying "that would take too much effort" are now things I can actually attempt.

Vibe Coding and the Developer's Role

I hear the term "vibe coding" a lot these days. It's the approach of giving AI a rough direction and having it write the code. Even if AI writes code in 20 minutes, I still review and refactor the code for essential core features myself. Of course, I give AI feedback and it makes revisions based on that.

Code written by AI works. But it's often complex or inefficient. Variable names don't fit the context, unnecessary abstractions get added, or error handling becomes overly defensive. I think developers now need to transform from people who write every line themselves to supervisors who manage the overall design and verify AI's output.

If writing code quickly used to be what mattered, now it seems like what matters is how well you can read and judge the code AI writes. And this judgment ultimately comes from the experience and knowledge you've accumulated.

There's one more thing that has become important here: the ability to translate business requirements into technical design. AI will build whatever you tell it to build. But "what should be built" is still a human domain. What does the user really want? What value does this feature bring to the business? What role should this component play in the overall system? These judgments cannot be made by AI. In fact, as implementation speed has increased, I feel the importance of design capabilities—deciding what to implement—has grown even more.

On the Counterarguments

At this point, there are some expected objections.

"Doesn't depending on AI weaken developers' fundamentals?"

Honestly, this is a valid concern. I fully understand the worry that developers who grow up in an environment where AI writes code for them might lack foundational strength. But I think about it a bit differently. When calculators came out, there were concerns that "mental arithmetic abilities will deteriorate." That may have actually happened. But did we give up using calculators because of that? Rather, thanks to calculators, we became able to handle more complex problems.

Similarly, thanks to AI, we can now focus on higher-level problems. The energy we used to spend memorizing syntax or API usage can now be spent on architecture design or understanding business logic. Isn't the very definition of "fundamentals" changing?

"Don't you still need to know how to code yourself to verify AI-generated code?"

Yes. That's why I said past experience and knowledge aren't useless. You need the experience of having written code yourself to spot problems in AI-generated code. However, how developers starting their careers will build that experience is definitely a point that needs consideration. Perhaps the learning approach itself needs to change. Something like coding with AI from the start while training to critically review AI's output.

"Doesn't this mean only people who are good with AI tools will survive?"

To some extent, yes. But this applies to all technological change. When Excel came out, accountants who were good at Excel had an advantage. When the internet came out, people who were good at searching for information had an advantage. The emergence of new tools always redefines existing expertise. What matters isn't resisting change, but how you redefine your strengths within that change.

Accept and Adapt

To be honest, until mid-2025, I felt resistant to AI writing code for me. I thought, "Is this really my code?" and felt somewhat uneasy. But now I've accepted that this is an unstoppable trend, and I routinely dedicate time to actively leveraging it.

Lamenting that you miss the old ways is meaningless. To not fall behind those who are achieving much higher productivity using AI, you must get on board with this change. As someone said, you need to know how to use a day like a month. To do that, moving with intention and making it routine is extremely important.

Let me use Kübler-Ross's five stages as an example. Denying AI, getting angry at AI-generated code, becoming depressed when facing the reality that it's more productive than you, going through the stage of bargaining with "maybe I should use it a little," and then reaching the acceptance stage of actively incorporating it into daily life. I can confidently say that whoever reaches this acceptance stage first will have a different future.

The age of coding hasn't ended—it has merely changed shape. Past education and knowledge aren't useless; they will become the foundation for better utilizing and verifying AI. Just because tractors were invented doesn't mean people stopped farming. The form has simply changed.

It's time to stop grieving and embrace the new era.

What stage are you at right now?

A Workplace with Stories to Tell

BJ Kim — Sat, 24 Jan 2026 10:05:02 +0000

A Workplace with Stories to Tell

A while ago, a colleague of 10 years resigned. When I asked why they were leaving a company they'd been at so long, they answered: "I no longer have anything to say. Every meeting, I found myself just repeating the same things."

On the other hand, there's a senior who's been at one company for over 15 years. They still speak passionately at every meeting, come up with new ideas, and debate with juniors. Even after working at the same company for 15 years, they didn't look worn out.

What's the difference? How can you work at a company for a long time?

I think this: If you can repeatedly talk without getting tired about things you want to say, it's possible.

What Does "Stories You Want to Tell" Mean?

The "stories you want to tell" I'm talking about here aren't routine work reports. Not things like "Here's a progress update" or "No issues" that repeat routinely.

"Wanting to" is an active action. It's a result that comes from values important to you as a person, messages you want to convey to others, or an attitude that goes beyond trying to fulfill your role—something that stems from that.

I have that experience too. When starting a new project, I had things I really wanted to say to the team. "What if we tried it this way?", "Users find this part inconvenient, I think we should improve it", "I wish our team would pursue this value."

When I talked about those things, I wasn't tired. Even if meetings went over 2 hours, I wanted to keep talking. On the other hand, when I was just doing what I was told, even 30-minute meetings exhausted me.

What Makes People Active

So what makes people active?

The first is instinct. When cold, we layer up; when hungry, we make food; when tired, we sleep. We do these without being told. It's the same at work. If there's performance bonus on the line, we work actively; if promotion opportunity appears, we move proactively.

The second is affection for others. Like always yielding to the person you love, we've all experienced being active when we're the one who needs something. If a colleague we like asks for help, we gladly help; if a leader we respect makes a suggestion, we voluntarily participate.

The third is when we discover meaning. When we know what we do helps someone, when we feel our role is essential to the team, when we're certain we're growing through this work—that's when people move actively.

I experienced this third one about 3 years ago. When team members said about a system I built, "This is really convenient, work has become so much easier thanks to you"—in that moment, my work gained meaning. After that, I kept working on system improvements without anyone telling me to.

The Root of Being Active: Love

But there's something more fundamental that runs through all three. I express it as love.

If you can know yourself well, cherish and love yourself, you become active. You move on your own for your growth, for your value.

If you can show interest in and love others, you become active. You gladly spend time helping colleagues grow and helping the team succeed.

If you can discover meaning in your work and love it, you become active. You take initiative to make better products, to build better team culture.

The Difference Between Liking and Loving

But here many people get confused. They can't distinguish between liking and loving.

Can you keep talking without getting tired at the liking stage? With just simple favor, you can try once or twice. But in the process, you become curious about the other's reaction, naturally develop expectations, and as disappointment accumulates, you stop repeating.

I was the same. When I first joined a team, I shared various ideas. But after being ignored a few times, I stopped offering opinions. It was because I only liked the subject. It was impulsive favor, an emotion below that.

If I had loved, I wouldn't have stopped. I'd still be repeating it without getting tired now.

So what is love?

The Definition of Love

Neuroscientist Dr. Dongseon Jang explains love this way: love is when the brain's reward circuit activates while conditional expectations disappear. In other words, it's an emotion that makes you act without transactional thinking like "If I do this, they'll do that for me."

Liking expects rewards. "If I work hard, I'll be recognized." "If I help, they'll be grateful." "If I share my opinion, it'll be accepted." So when expectations aren't met, disappointment follows and you quit.

Love is different. The other person's happiness itself is the reward. "I'm happy just seeing this team succeed." "The growth of my colleague itself brings me joy." "Making users' lives easier is my fulfillment." You can continue even without immediate recognition or reward.

I realized this around my 6th year. It was okay even if a feature I made wasn't immediately praised. When someone said 3 months later, "That feature from back then made work easier"—that alone was enough. In that moment, I realized I love this work.

How to Work at a Company for a Long Time

Ultimately, the method for working at a company for a long time is simple. Love the company, love colleagues, love what you do.

Then stories you want to tell emerge. Stories you can tell repeatedly without getting tired. Even after 10 years, 15 years, you can still speak passionately at meetings.

Finding a Workplace You Can Love

Of course, you can't love every company. Some companies are hard to love. When values don't match, when you don't fit with colleagues, when you can't find meaning in the work.

Then you have two choices.

First, try to find something to love at your current company. Even if not the whole company, look for something to love among your team, colleagues, projects you're responsible for. It might be closer than you think.

Second, leave to find a company you can love. Sometimes it's better to find a place where you can naturally love, rather than forcing yourself to love.

I've been through several companies. And joining Plab, I've led the development team for a year. Not a long time yet, but there's been definite change.

At first, I was busy adapting to the new environment. But as I talked with team members one by one, solved problems together, and watched them grow, I realized: I've come to love these development team members.

And now I'm going further, trying to love the company itself and the role the company expects of me. It's not perfect. The reason I use "trying to" is that I'm still in the process. Like I came to love the team members, I trust I'll gradually come to love the company and my role more.

What about you? Do you have stories you want to tell at your current company? Stories you can tell repeatedly without getting tired?

If you do, congratulations. You're already loving. Please nurture that love well.

If you don't, I recommend looking for one. It doesn't have to be the whole company. Start small, from one colleague, from one project. Look for something you can love.

As that small love accumulates, someday you'll be a senior who's been there 10, 15 years. Still speaking passionately, still not tired, still overflowing with things to say.