Surviving the FOMO of
Programming Influencers
Stories about feeling anxious after watching programming influencer videos tend to end with advice like "don't compare yourself to others and study at your own pace," which isn't wrong, but that alone is not enough.
Some people go beyond simply introducing new technologies and talk as though you'll be finished as a developer if you don't know them, so I think it's worth reflecting not only on why I feel anxious, but also on why that person keeps giving me reasons to feel anxious in the first place.
What is FOMO?
Fear of Missing Out is the anxiety that everyone else is having great experiences while you alone are being left behind. Research by Przybylski et al. examined the relationship between this anxiety and social connectedness and media use, but since it did not directly study developers' career anxiety, I want to apply the concept here to tech content instead: the situation where the priority of learning is thrown off not by gaps discovered in actual work, but by the feeling that others are pulling ahead. 1
This anxiety is compounded by the nature of social media. Our world is connected through social platforms and YouTube. Social media algorithms prioritize content with high engagement.
That is because sensational titles, dramatic claims, and fear-inducing framing generate more clicks, views, and shares.
The problem is that algorithms construct a "highlight reel" that selectively surfaces influencers' achievements. People naturally look to others as a reference point for evaluating themselves, and when an algorithm repeatedly exposes only the "peak moments" of those comparison targets, distorted comparisons arise between the viewer's everyday progress and those curated highlights.
There is a typical path to becoming a developer influencer that is commonly discussed in online communities.
The core of this path is called the "FAANG-to-Funnel pipeline." The big tech job itself is not the goal; it functions as a credential to talk about online. In this structure, the ability to actually write code is generally secondary,
and a significant number of these people "don't love writing software — they love talking about writing software."
The shift that occurs is: "Software is no longer the product. You are the product."
This type of trajectory, fleshed out as a story, tends to go something like this.
At first, real field experience becomes content.
Suppose a developer who was building products at a company starts explaining their experiences on video: why a database query was slow, which abstraction they added that ended up making changes harder, why the first suspected cause during an outage turned out to be wrong. Stories like these are genuinely useful. The explanations include the conditions under which things applied and the trial and error involved, and viewers can learn decision-making processes that wouldn't be visible from a textbook definition alone.
At this stage, that person's expertise is tied to specific experience. What they worked on, at what scale and in what environment, what failed, and how they made sense of that failure — these are the foundations of credibility. They don't need to claim knowledge of every language and framework to be valuable; in fact, the more precisely they describe the scope of what they've experienced, the clearer it becomes which parts apply to other environments and which don't.
But as the channel grows, the demands on the creator change. Someone who used to casually document development stories becomes a person expected to produce videos on a regular schedule, and once those videos account for a meaningful share of their income, choosing the next topic is no longer a side hobby they can get to when they have time.
Planning, scripting, building examples, filming, editing, choosing titles and thumbnails, watching for reactions — all of this becomes part of their schedule and their life. But no matter how many projects a person works on, lived experience is finite. Eventually they run out of things to say from personal work, and around this point the drift toward trending tech topics and trend-based content begins.
Where they once made content from experience gained in their actual job, now there are situations where they choose what to experience in order to make content.
And once this starts happening, the developer thinks seriously:
"Should I keep developing, or should I become a content creator?"
Development is hard. That's just the reality. If I get laid off, can I still stay current with the stack I've been studying? I'm using React here, but what if I suddenly need to use Vue.js, like that Chinese company I visited the other day?
A content creator is self-employed and, unlike a developer, doesn't seem to have the risk of getting laid off. Meanwhile, the YouTube channel suddenly starts getting traction.
This is the trap. Summarizing what Korean YouTubers openly share among themselves, the pattern goes like this.
Step 1, Early Boost Effect: In the early stages, YouTube's algorithm actively surfaces videos to help a channel establish itself on the platform.
Step 2, Revenue Plateau: Even as full-time YouTubers grow their subscriber counts (say, from 200,000–300,000 to 1.5 million), after a certain point views and revenue stop growing significantly and either stagnate or slow down.
Step 3, Need for Additional Revenue Models: Because they hit the limits of algorithm-driven and platform revenue, prominent YouTubers end up building a diversified second revenue stream through outside sponsorships, personal activities, businesses, or sub-channels.
Usually, once revenue starts flowing from the early boost effect, people start betting everything on YouTube. They imagine their future as a top creator — landing ads, courses, sponsorships, and memberships.
But paradoxically, that means living under the constant threat of being "fired" every day by the algorithm and by the public. A developer can at least prove the day's work when code runs in production, and signing a B2B contract provides legal protection and predictable cash flow. An influencer's boss, by contrast, is a fickle public and an opaque YouTube recommendation system. There is no guarantee anywhere in the world that today's viral video will repeat tomorrow.
Maintaining expertise versus maintaining a channel
Of course, the expertise doesn't just disappear. But programming has trends. To be precise, programming is multifaceted.
Foundational principles like bug tracking and drawing system boundaries don't change much. These paradigms are stable, but precisely because they've been covered so thoroughly, they offer no competitive edge as content.
They simply can't generate views and clicks as content.
But the job has now become one where you have to live off popularity with a mass audience.
So what can you do? Covering foundational principles doesn't bring views, and without views the channel dies. Content creators caught in this dilemma have a fixed set of strategies to choose from. Fear marketing is one of them.
The grammar of fear marketing is remarkably repetitive.
First, trend chasing. Every time a new technology appears, the message plants the fear that "you're done if you don't know this." If the technology actually takes off, the creator gains the authority of "I saw it first"; if problems emerge, they quietly move on to the next topic. The cost of failure is paid by the viewer. And the programming culture centered on Silicon Valley actively encourages this, because selling software as SaaS is in some ways like a pyramid scheme. Even if that technology fails, the next video will feature yet another "you're done if you don't know this." The facial expression is the same.
Second, disparaging specific technologies. Claims like "PHP is bad" or "jQuery is dead" torch existing technologies and push people toward switching. Technology choices always involve context and tradeoffs, but that kind of nuance doesn't generate clicks. "X is over" makes a far stronger title than "X is still a valid option." PHP kept quietly powering a large share of the web long after those videos went up. It just doesn't post on YouTube.
Third, regret videos. By showing "how much I lost by not knowing this," they trigger the viewer's anxiety. Viewers feel the pressure: "If even that person went through it, I need to learn this now." Regret is one of the most powerful FOMO triggers. And that person is doing just fine today with the very technology they claim to regret. Search for React on YouTube — a framework that frontend developers both love and hate — and you'll find countless regret videos. Nobody points out that the creator is thriving right now with that same technology.
Fourth, manufactured fear. Claims like "AI will replace developers" or "coding will disappear within five years" are the prime examples. In reality, AI is becoming a tool for developers, but the speed and direction of that change are far more complex. Complex explanations, however, don't generate views. Only simple fear drives clicks. The editing on that video was still done by a human. For now.
At the heart of this grammar sits survivorship bias. Only successful cases are shown; the stories of the many who failed are omitted. "Developers who succeeded on YouTube" are shown, but "the many developers who started a channel, got no viewers, and quit" are not. When only the stories of successful people are repeated, viewers come to believe it is a replicable path.
And we always follow path dependency. That person succeeded that way, so I will too. Of course. Even I, writing this post, follow the path of other well-known programmers — building a website nobody reads and writing posts nobody reads.
Selling urgency about the future
A substantive technical explanation has a defined scope of what can be said. You explain what environment you used something in, you show the conditions under which it doesn't work well, and where you don't know the answer, you pause before drawing a conclusion. By contrast, "you'll fall behind if you don't know this technology now" can sound relevant to a far wider audience because even people who have no immediate use for that technology take it as a problem for their own career.
If first-hand experience from the field has decreased but you still need to produce content that pronounces on the latest trends, the natural result is filling topics with future projections rather than concrete usage experience.
Good and Hyman's research reported that, in scenario experiments involving imagining leisure-oriented services or experiences, FOMO-triggering messages can influence purchase intention. The intention could be strengthened through anticipated enjoyment and the sense that one's self-worth would rise, or weakened by the expectation of regretting the expenditure. Connecting the emotion of potentially missing out to purchasing decisions is a studied marketing technique.2
For instance, a claim that a certain tool reduces a specific type of work gets inflated into a projection that users of that tool will completely replace all other developers. The first claim can be verified by specifying the task and conditions for comparison, but the second changes in meaning depending on how you define the role, the organization, and the time horizon. Strip out the conditions, though, and what remains for the viewer is less a basis for comparison and more a sense of urgent pressure to do something right now.
When that pressure is combined with course sales, paid communities, or specific product promotions, it deserves even closer scrutiny. Introducing a tool and teaching how to use it is a legitimate business in itself, and a technical explanation doesn't become wrong simply because money is being made. But if someone argues that you need to get on their path right now, without offering adequate evidence for the claim that your existing skills will soon be worthless, then you need to examine not only what is being taught, but also how the urgency to buy was constructed.
This sales grammar sends viewers who came looking for specific information the message that they need to keep following along to stay safe. Even when a specific problem has been solved and it would be fine to tune out for a while, it tacks on the explanation that falling behind on the next trend means falling behind all over again.
The appeal to repeat subscriptions and purchases ends up leaning on anxiety rather than newly demonstrated value. Why viewers actually decide to buy is something that would need to be verified separately, but at minimum, what the seller offers as the reason to buy can be examined in their own public words.
Some people genuinely believe in the alarming forecasts they share, and there are changes that truly do require urgent action. So you can't simply dismiss an explanation as false just because it made you anxious. There are three points worth critiquing: whether the evidence and conditions behind a forecast are absent; whether an unverified possibility is being presented as an inevitable future; and whether the response to that future is being narrowed down to the seller's own product. These are things you can examine without knowing the person's inner motivations. I wrote "without knowing their inner motivations," but honestly, knowing them makes it even more interesting. You don't need to know, though.
Influencers themselves may also fear being left behind
Does someone who sells FOMO always have the luxury of coolly manipulating other people's anxiety? I don't think so.
The most interesting thing at this point is that, without realizing it, creators can come to genuinely believe they are predicting the future. The channel operator may feel anxious about losing viewers' interest if they miss this wave, and when another channel introduces a new tool first, they may feel pressure to offer an opinion quickly even before they've used it enough themselves. The algorithm hones this psychology to a fine edge.
Seen this way, the two anxieties are connected. The operator fears being forgotten if they miss a trending topic; the viewer fears falling behind if they don't learn about it. Every time something new appears, the operator feels they must explain it quickly and the viewer feels they must learn it quickly, yet neither side has had enough time to confirm what actual problem that tool solves in their real work before moving on to the next topic.
There is an old saying in casinos.
"Don't play the game. Run the house."
So who is playing the game here? Someone who sells talk about coding rather than coding itself thinks they've finally crossed over to the house's side. But there is a separate house running the table they've joined. No matter how well a video performs, the platform takes its cut first. The influencer is a gambler pretending to be a dealer, and the real house is the algorithm.
Separating the scope of judgment
It is natural to trust someone who once gave you a good explanation.
I trust my parents. Sure, they watch YouTube misinformation every day and then lecture me at length, but I trust them because of the good experiences I had growing up. Programming influencers are no different. It's not strange to feel warmth and trust toward someone who explained a topic well.
The issue is the scope of that trust. You can watch a new language introduction by someone who explained database operations well. But there is no reason to take it on faith that this same person also has accurate knowledge of a developer's entire future. The ability to introduce a new tool and the ability to judge whether that tool is essential for your career are separate matters. Viewers need to keep adjusting how far they extend their trust.
That said, there's no need to go hunting for another famous person to prove a famous person wrong. One side says you're done if you don't learn this now; the other says it's all hype. If all you're doing is figuring out which side to join so you'll feel at ease, you're still moving within a problem that someone else defined for you. Subscriber count does not guarantee the scope of someone's judgment. Trust the person, but apply judgment by domain.
So how can you avoid getting swept away?
Honestly, there is no method. To avoid being swept away, you'd have to stay out of the water, but as long as you live as a developer, you can't avoid the water. New technologies emerge, companies change, and the keywords in job listings change — you can't escape that. The algorithm decides what we see, and we feel anxious watching it. We go looking for more content to escape that anxiety. There is no way to break this loop.
But stepping back slightly, getting swept away is also a kind of fun. If you're going to get swept away anyway, it's better to learn something while you're at it. When a new tool comes out, try it once; when the trend passes, you can just say "that was fun back then" and move on. You don't need to chase every trend, but avoiding them entirely takes the fun out of things. Being swept away can be active, too. Being passively swept along and deliberately jumping on a wave for a ride are different things.
Of course, saying this doesn't make the anxiety disappear. But rather than trying to eliminate anxiety, isn't it better to play around with it? The casino saying was not to play the game but to run the house, yet we are already playing the game. In that case, we may as well enjoy it while we play. You might lose money. But you can still have fun. If you're going to get swept away either way, you might as well laugh while it happens.
That said, even while being swept along, you need a raft. Without a raft, you just keep drifting, carried entirely by the current. The raft is not some technology you can't use right now; it is the work you actually have to do right now.
Most of what YouTube teaches is technology you can't use right now.
"This will be the dominant approach within five years" or "learning it now will pay off later" are the current, not the raft.
The work you actually have to do right now, by contrast, is something due tonight, something someone will check on tomorrow morning. The current may carry you anywhere, but the raft knows where it needs to go.
I've been surviving in Korea's ERP domain for quite a long time now. In tax affairs, starting in 2027, labor payment statements will shift to a monthly submission cycle, and semi-annual remittances will become monthly. Right now the simplified payment statement fields for withholding tax on employed workers only open in June and December, and I need to make them open every month. I need to add a revision year to a settings field, use the year the law changes as a rule, and set it up so that only the numbers need to be changed going forward.
This work won't generate views if uploaded to YouTube. No one will watch a video titled "How I Handled the 2027 Monthly Labor Payment Statement Requirement." But this work actually solves someone's real problem.
By the time I finish this, some new technology will probably have appeared. Someone will say you can't survive as a developer without knowing it, and I'll probably click on that video. Honestly, because it's interesting. I might even feel anxious enough to study it for a few days.
But the fact that I didn't watch that video doesn't make tomorrow's work disappear. Conversely, watching the video diligently doesn't solve today's problem either.
I will keep getting swept away. When a new language comes out I'll be curious, when I see an impressive demo I'll be amazed, and when it seems like someone is so far ahead of me I'll feel anxious.
Even so, I intend not to forget where the raft I'm riding is supposed to go, even as the current carries me along.
For now, tomorrow I need to fix the payment statement screen first.