The Illusion of Talent

Maybe it is because the job market is difficult, but I have seen quite a few juniors give up on becoming developers. “Give up” sounds a little dramatic. More precisely, they quietly remove the profession of developer from the list of possible lives they can imagine for themselves.

Most people begin in similar ways. Frontend looks fun. It feels good to build something directly. It is fascinating to see the code you wrote appear on the screen right away. Then they look at the job market, hear stories about AI, see people around them who are absurdly good, and at some point start saying that maybe they do not have talent for development.

I have sometimes been told that I have talent. The talent they are talking about is probably closer to the ability to enjoy development. When I see new technology, I get curious. I look up why it works the way it does. If something feels strange, I cannot just move on. More accurately, it is less a talent for development and more a high level of intellectual curiosity. That curiosity just happened to fit well with the work of development.

But when we start treating that as the only talent a developer can have, things become a little strange. It creates an atmosphere where becoming a developer seems to require loving technology unconditionally, enjoying hard problems, doing side projects on weekends, and trying new frameworks faster than anyone else.

There is an image people unconsciously picture when they hear the word developer. Someone wearing a checked shirt, always carrying a laptop, a little nerdy or geeky, and happy to solve difficult technical problems. Someone like Mark Zuckerberg.

Of course, people like that exist. And it is true that those people hold one strong card as developers. But the good developers I have seen did not all look like that. Some cared about fashion. Some liked spending time with people. Some were more curious about how a service is used by people than about talking about technology all day. They often doubted themselves simply because they did not resemble the “correct” image of a developer they had in mind.

I knew a friend who was excellent at organizing meeting discussions. Developers knew which parts of the design system were uncomfortable, but they could not explain it properly to designers. From a developer’s perspective, the inconvenience was obvious, but from a designer’s perspective, it was hard to feel why it was a problem. They were speaking different languages.

That friend translated the problem in the middle. They changed the inefficiencies developers felt into sentences designers could understand, and organized the standards designers cared about in a way developers could accept. In the end, a problem that had taken a long time was solved fairly quickly. That friend probably did not think of themselves as an extremely technical developer. But in that situation, they were using the most important card.

I also had a friend who said their confidence dropped after the AI era arrived. New workflows keep appearing. Someone says they built something in a day with AI. Someone else says developers are finished. In that kind of era, they felt too slow.

But that friend was still someone who woke up in the morning and searched for things like operating systems, networks, and data structures. From today’s perspective, it may look a little old school. They were curious about principles before tools that immediately improve productivity, and even when an output appeared, they dug into why that output appeared. To me, they had a side closer to a researcher than a developer. The problem is that this kind of card is hard to see in an atmosphere that demands visible results quickly.

Among people who give up on becoming developers, many are not people without cards. They are people who do not know that the card in their hand is a card. The ability to document well, identify the core point in a meeting, persuade people, understand business, quickly sense user discomfort, or follow principles to the end. Strangely, these are not often called development talent.

Instead, many juniors keep looking for something like a royal straight flush. Am I naturally brilliant at writing code? Can I solve algorithms faster than others? Can I understand new technology the moment I see it? If they do not have that kind of card, they feel as if they should not enter the game at all.

But real work is not that simple. Just as drawing comics requires more than drawing and story, being a developer requires more than code. Of course, code matters. Without fundamentals, it is hard to last. But saying fundamentals matter is different from saying only a specific type of person can become a developer.

Some people survive by digging deeply into technology. Some survive by understanding products well. Some survive by organizing complex team problems. Everyone enters the same game with different cards.

These days, I like the phrase process asset more than sunk cost. Preparing for jobs for a long time and failing. Building a portfolio and getting no attention. Spending an entire day on an Instagram magazine with fewer than 100 followers and getting no likes or follows. Days like that easily become pathetic days. It feels like time was wasted, there were no results, everyone else is moving forward, and I alone spent energy in a strange place.

But whether that day remains only a sunk cost or becomes a process asset is ultimately a matter of interpretation.

If you spent the whole day thinking about content and received no response, that can be a failure. But at the same time, it can be the day you learned which sentence was not read. It can be the day you learned which thumbnail failed to make people stop. It can also be the day you confirmed which topic you can hold onto longer than you expected.

Development is similar. Failing an interview can simply be a rejection, but it can also be the day you learned which concepts you cannot explain. A collaboration that went badly can simply be a difficult project, but it can also be the day you learned what kind of communication you are weak at.

Even on days that do not look like the usual “productive life,” if you did something, there is usually something left inside it. The question is whether you can interpret it as something that remains. If you think nothing remains, then nothing really remains. But if you look at the failure of that day in slightly higher resolution, small cards strangely appear.

The experience of speaking in front of people, finishing one document, being rejected, learning what you do not know, or learning how you fall apart when you hold onto something for a long time. At the time, they look insignificant, but later they get used in completely different places.

So I want to tell juniors who dream of becoming developers not to ask too quickly whether they have talent or not. That question has lower resolution than it seems. You need to look more closely first. Do you really want to become a developer? Do you want to join a good company? Do you want recognition in the industry? Do you want to earn a lot of money? Or do you simply want to become someone who makes things?

If you cannot organize your desire in high resolution, every anxiety gets blurred into the word talent. “I guess I cannot do it because I have no talent.” That sentence is too easy, and that is why it is dangerous.

The person who waits for a royal straight flush before entering the game never enters the game. You have to reveal your cards first. Even cards that do not look very good can show power in strange places once you use them. And once you have played the game, you gain cards you did not have before.

A card from enduring failure. A card from persuading someone. A card from meeting a deadline. A card from seeing a result with no response and still making it again. When those cards accumulate, things that did not look like talent at first can become surprisingly useful weapons.

I do not think there is only one talent developers need. What matters more is how each person can fit their strange cards into this work. The people who do that well are the ones who stay for a long time. Not people who began with a completed hand, but people who keep checking their cards, interpreting failure, and turning ordinary experiences into process assets. In an era like this, those people may go farther than we expect.