When did you realize that pursuing technology has no future?

This article is exclusively sponsored by #BCGame @bcgame

Many newcomers just entering the industry, including myself back in the day, believe in a dead-end principle: as long as my skills are top-notch, I am irreplaceable.

So we hustle like crazy. Learning Java, Go, Rust, reading source code, tackling algorithms, building microservices, working on cloud-native. Today still tinkering with Spring Cloud, tomorrow needing to learn Service Mesh, the day after AI large models become popular, rushing to learn Prompt Engineering.

We think this is called progress; in fact, it’s cyber fatigue.

You think you’re building a technical barrier, but actually, you’re helping your boss verify the feasibility of new technologies.

In the internet industry, the depreciation rate of technology is faster than the decline of your pre-sold house. The framework you’ve painstakingly studied for three years—Google or Facebook releases a new version, or changes their architecture philosophy—your so-called “dragon-slaying skills” instantly become scrap paper.

But this doesn’t mean learning is useless; it’s just that your efforts might be misdirected. Instead of chasing frameworks that become outdated in three years, it’s better to focus on the underlying logic that won’t change for a decade. For example, while you’re still debating whether to use Spring Cloud or K8s, the real experts are thinking about data consistency in distributed systems. If you want to break out of the framework cycle, I recommend reading the book hailed as the backend bible, *Designing Data-Intensive Applications* (DDIA annotated edition). It discusses the essence of distributed systems, databases, and system design. Understand these, and no matter what framework becomes popular tomorrow, you’ll see through its core.

Do you remember those guys who used to work on Flash? Or the experts who developed Symbian systems?

Are they not working hard? Are they not smart?

When the times leave you behind, they won’t even say goodbye.

The scariest part is that our pride—fast learning ability—is actually a consumable attribute that capital loves most.

Because you learn quickly, you are cheap.

In the past, an experienced traditional Chinese doctor became more valuable with age because experience couldn’t be copied. Now? A 35-year-old senior programmer demands a high salary—that’s called low cost-performance ratio. A 23-year-old recent graduate, handed two manuals, copying and modifying code on GitHub, can get started in a month.

At this point, you might say, I have experience, I can avoid pitfalls.

Stop kidding yourself. In most CRUD business scenarios, you don’t need such advanced skills. So what if your code is a bit sloppy? Just add two more servers. What if there’s a memory leak? Restart the server at midnight, problem solved.

For bosses, it’s enough that it runs.

Your elegant code, your design patterns, your architectural thinking— in the boss’s eyes, they’re all less valuable than that flatter who can drink with him, draw big pie charts, and make PPTs look dazzling.

This is the phenomenon of bad money driving out good.

When you realize that the underlying source code you’ve studied for half a month is less likely to get promoted than the PPT engineer next door who constantly shouts about empowerment, grasp points, closed loops, and granularity, it’s time to wake up.

The greatest sorrow for technical personnel is that we are always too far from the money.

We are productivity, but not the masters of production relations.

You develop an impressive recommendation algorithm that increases user retention. Who gets the credit? Operations, product, or even the business side that negotiated channel partnerships.

Why?

Because in business logic, technology is just a tool.

It’s like building a house—you’re the bricklayer. No matter how straight the walls are or how fast you move bricks, the ones who ultimately profit from selling the house are the developer, the real estate agent, or even the speculators—only not you, the bricklayer.

Moreover, technology often becomes the scapegoat.

When the system crashes, you take the blame. When deployment is delayed, you take the blame. When there are many bugs, you take the blame.

But what if the business doesn’t succeed?

The product manager will say: I also want to do well, but the technology doesn’t support it, this feature can’t be implemented, the schedule is too long.

See? Such a perfect closed loop.