By age 30, programmers have finally climbed from code slave to white-collar worker, yet they can no longer keep working and constantly face the danger of unemployment. Thirty is an age that programmers simply cannot afford to mess with. Tomorrow, which way to go?

I. The 30-Year-Old Phenomenon

In officialdom, there was once a "59-year-old phenomenon" where officials would grab as much as they could at age 59. Obviously, power expires and becomes void—if they don't grab now, they will retire and have no chance.

In the programmer circle, there is also a 30-year-old phenomenon. Of course, if you have an iron rice bowl, such as in a state-owned enterprise or government organ, then you cannot understand the feelings of the working class at the bottom. At the same time, congratulations on becoming a member of the establishment, where you can work without worries until retirement.

Everyone understands the 30-year-old phenomenon, but it is not easy to define. Here are a few manifestations—perhaps you will feel a pang of recognition.

Facing a career bottleneck: can't write code anymore, and climbing the ladder is difficult.

Salary is relatively high, overtime has decreased, the back waves chase the front waves, and there is unemployment pressure; life pressure soars, so they dare not change jobs.

An unspoken industry rule restricts programmer recruitment to under 30, making job-hopping difficult.

The 30-year-old and 59-year-old phenomena seem unrelated, but they actually stem from the same cause: value depreciation. An official in office is like an emperor; once retired, he becomes a commoner—depreciation is natural. The same is true for programmers. As the saying goes, "at thirty one stands firm." Once around 30, facing marriage and children, on the one hand they need a high salary to support their family, and on the other they can no longer devote themselves wholeheartedly to work as before, so their cost-performance ratio plummets. At the same time, a flood of cheap newcomers enters, often using the latest technologies, so the older generation of programmers can only gradually step aside.

II. Irreplaceability

The cause of the 30-year-old phenomenon can only be found in programmers themselves.

Of course, we can also analyze the industry, society, government, system, and many other aspects to identify shortcomings. These analyses may not be unreasonable, but they are definitely useless because we cannot change them. As the saying goes, "A bitter life cannot be blamed on the government, and bad luck cannot be blamed on society." Looking for causes externally will only fill us with complaints, making us feel born at the wrong time and utterly depressed all day.

To find causes within ourselves, try asking yourself: "Why has my cost-performance ratio declined? Why should the boss hire me and pay me a high salary? What determines a person's value?"

You might list a very long answer, but I think it can all be condensed into one sentence: "A person's value is determined by his irreplaceability." Irreplaceability can be understood as the cost the boss needs to pay to replace you.

Because your replaceability is high, your cost-performance ratio declines. Conversely, because your irreplaceability is high, the boss gives you a high salary. Isn't that the case?

There is a little story:

When a technician retired, he warned his apprentice: "Talk less, do more."

Ten years later, the apprentice had also become a technician. He went to his master and said with a bitter face: "Master, I have always followed your advice, just burying myself in hard work, but those with worse skills than me have all been promoted and gotten raises, while I still take the same salary as before."

The master thought for a moment and said: "Take a leave of absence. If a lamp is always on, no one will notice it..."

The apprentice suddenly understood. He really took a week off. When he returned to work, the factory director found him and said he wanted to give him a raise. It turned out that during his absence, the director discovered that the factory already could not do without him.

The apprentice was very happy. Afterward, he took a few days off from time to time, and every time after asking for leave, the director would give him a raise. One day, after taking leave, he was preparing to go to work, but the director told him: "You don't need to come to work anymore."

The apprentice went to his master in distress. The master said: "I hadn't finished that day. A lamp can occasionally go out once, but if it always goes out, the nature of the matter changes, because no one needs a lamp that flickers on and off."

In the story, because the apprentice was irreplaceable, the director gave him a raise; later, because other lamps lit up, he was replaced, the director no longer needed him, so he got the sack.

So in the final analysis, we still need to improve our irreplaceability. Otherwise, once the boss feels that replacing you costs little, you will face the danger of possible unemployment.

III. Where Is the Way Out?

So how can programmers improve their irreplaceability when they reach 30? Do we intend to be programmers all our lives? May I ask where the road is?

As someone who has been through it, a senior programmer, I think there are several directions to choose from:

(1) Becoming a Technical Guru

Actually, it is no problem to be a programmer all your life. What matters is that you must become an irreplaceable programmer—that is, become a technical guru who can solve problems that ordinary programmers cannot. There are two versions of a technical guru:

The first is the enhanced programmer. You are still a programmer, but you are a very formidable one. With years of accumulation, you are no ordinary person in both breadth and depth of knowledge. From assembly to Java, you are proficient in everything. You care about data structures and algorithms, have unique views on system optimization, know design patterns like the back of your hand, and also have a complete toolbox and your own specialized class libraries. In fact, the enhanced programmer has very unique value. Unfortunately, they are very rare in reality, because talent is always scarce for any company. The boss has sharp eyes—how could he ignore a technical ox like you? Before you even become a true guru, you would have been appointed as a system architect, project manager, or an even higher position. Therefore, it is often impossible to simply guard your own small plot of land and leisurely be a guru.

The second is the upgraded programmer. Although your inner essence is still a programmer, your position has been upgraded, and you become a system analyst or system architect. This is a very natural and realistic choice. There is no chasm between programmer and system analyst or architect; just one step away, you can drive from a rugged mountain road onto a broad highway. But this step is not easy. It takes years of continuous thinking, learning, and practice to transform from a chrysalis into a butterfly.

(2) Becoming an Industry Expert

Industry experts are also an indispensable role in a company. They know the company's industry knowledge, business processes, and details inside out. Industry experts are generally not supermen hired externally who only understand business but not technology, but rather often grow up from programmers after years of hard struggle. As an industry expert grown from a programmer, you often also serve as a system analyst. In a company, there are many people with a general understanding of the business, but expert-level people are often few. For the 30 years of career ahead, you must become an expert.

(3) Moving Toward Management

The first step toward management is generally being appointed as a project manager. In most IT companies, the project manager is the smallest management position. You may not feel much surprise, and your salary may not increase much, but this transition can be said to be one of the most important changes in your life.

Do not underestimate the project manager. Some say that the project manager is an ancient profession. Others say that the 21st century is the century of project management. In fact, since humans became organized, there has always been project management. In the past, a project manager might have been a tribal chief; a collective hunt or an attack on a city or stronghold could be regarded as a project. Project management knowledge can be applied to all aspects of our lives, from the implementation of a moon landing project to the organization of a family gathering—all are inseparable from project management.

An excellent project manager needs not only a high IQ but also a high EQ. It is no exaggeration to say that if you are competent in project management, you can be competent in all management positions at the tactical level, and even your quality of family life will be raised to a new level.

However, becoming an excellent project manager is not an easy thing. It can be said that a certain amount of talent is needed. Some people pick it up without a teacher, while others can never learn it. Programmers belong to a high-IQ group, but often lack EQ, which dictates that only a few programmers can grow into project managers, and those who become excellent project managers are very rare.

If you feel that none of these aspects are suitable, then you still have several ways out:

The first is to muddle through steadily.

Speak honest words, be an honest person, do honest things, and take an honest salary. The company also very much needs employees like this, and generally they will not suffer the fate of being fired. The second is to switch careers or start a business.

Because this industry no longer suits you and has no greater room for development, you have to switch careers. If you can switch, it is not necessarily a bad thing. Perhaps in a new environment, you can stimulate stronger energy and create a cause of your own. As for starting a business, it is even more challenging. I suggest that before starting a business, you should already have become an excellent project manager. Think about it: if you cannot manage a project, how can you manage a company?

Source: OSCHINA