Before I felt anything, the year was already ending. I sigh at how time's arrow flies past like this, and my life ticks down another year. Looking back, I've been a code monkey for over seven years. Though I haven't made much of myself, I haven't completely wasted the time either. A brief summary seems in order, so as not to lose track of the days gone by, and it will greatly benefit the road ahead. If this post can be of any help to you, I'll be very pleased.

A career is a marathon made of countless connected runs

In elementary school, we clearly knew we'd graduate in 5 years (I went through the five-year system back then; seems some places still do). No matter how much you hated your teachers, classmates, or the school, you knew it would end in at most 5 years. Same with middle school and high school: in three or four years, it passes quickly, and all the joy and sorrow soon fade away. College is even more so—from the day you step onto campus, you start the countdown, knowing that one day four years later you'll leave. No matter how you cherish it or squander it, time still runs in one direction at its eternal, unchanging speed.

But the workplace? After 5 years, you're still working, and you have to keep working. After 10 years, 20 years, 30 years, even 40 years, we still have to work. Even if you quit, you'll have to join another company, and the new job is no different in essence from the last. Once you understand that a career is a 40-year cycle, you realize it's an ultra-long marathon—no middle-school sprint, no college-entrance sprint, and certainly no "get into a good university and then you can just play around." There's no point sprinting with reckless abandon; it wouldn't do any good anyway. What matters more is continuous learning—yes, decades of continuous learning.

The only way to become a master, or a big shot (da niu), is constant learning

Don't dream that getting into a big company, joining an awesome team, sitting next to a big shot, or attending more offline events will make you a big shot. That's all "too young, too simple." Why would a big company want you? Why would an awesome team want you? First, you need some real skills. As for getting pointers from a big shot—that's luck. Maybe you've watched too many TV dramas: you fall into a valley and run into a white ape with the Nine Yang Scripture hidden in its belly? Or you roll down a cliff, see a giant eagle, and learn Dugu Nine Swords? With millions of code monkeys across the country, what do you think the odds are of running into a master? And how likely is a master to be willing to talk to you? Dreaming of a master teaching you hand by hand? Unless you're their f*ck buddy.

Of course, some people really are lucky enough to get guidance from a master. But I believe that for the vast majority, even if a big shot is right beside you, you won't have enough chances to get their guidance. Companies hire us to work, to create value, to make money for them. Big shots have heavier workloads and more things to deal with—why on earth would they be obligated to guide you?

Big companies do have abundant resources and materials, and more training opportunities, but you still have to go look, listen, and learn yourself. As for various offline events, the majority are just advertising. The other talks mostly skim the surface—getting real substance ("dry goods") is impossible. How much can they say in a few dozen minutes? And how much can you absorb? So offline events are good opportunities for promotion, broadening horizons (you can hear many concepts), and expanding your network (you can indeed meet many people—big shots and your peers)—but not for learning.

In one sentence: if you want to become a master, you still have to learn down-to-earth—devour books, read code, write code. There's no other way. On this, you can refer to a big shot's article (Writing business code every day—how do you become a technical big shot?), which I think makes a lot of sense.

Choose an industry, or a technology, and then go deep

Although I don't advocate making five-year plans like some people do—because our industry, companies, projects, and personnel change too fast, and these uncertain factors will throw off all plans, especially long-term ones—we still need goals. I believe for most people, the ultimate goal is nothing more than financial freedom. How do you achieve financial freedom? Luck does play a part, but what matters more is hard strength. What is hard strength? It's being able to solve problems others can't. For example, the boss wants to develop a certain line of business, and you know the business rules inside and out, and can lead a team to get it done. Or, when a technical problem comes up, you can crack it. Without real strength, mere luck won't help—even if you witnessed the rise of Taobao, you still might not be financially free today.

Where does hard strength come from? It comes from accumulation. Accumulate what, to become more and more valuable? Nothing other than industry or technology.

What is an industry? Autos are an industry, finance is an industry, clothing is an industry, travel and transportation is an industry, and so on. And what is technology? Security, audio, WebKit, graphics, deep learning—these are all technologies. Being in an industry, the technology may not be complicated; it might all be run-of-the-mill. But if you can come to understand an industry deeply—its rules of the game, its pitfalls, its policies and regulations, its risks, how to get maximum returns—these are things you only learn after spending time in the industry. Technology is easier to understand: using packaged technology is easy. For instance, WebView is very convenient to use, but its underlying technical implementation—WebKit—is extremely complex, and you can't figure it out in just a few years.

Of course, it's not easy to keep digging deep in the same field (whether industry or technology)—it takes luck. But understand this: only by going deep in one industry or one technology can you maximize your value. So when you have a choice, move as close to your goal as possible.

Responsibility weighs more than technology

A programmer's work, whether in internet or enterprise software, is engineering—it's the application of technology. In most cases, most people won't encounter technologically unsolvable problems or world-class challenges at work. In other words, the problems you meet at work—even if you don't know how to solve them—can be quickly resolved by consulting references, books, the internet, and colleagues. Moreover, writing clean code, testing thoroughly, and making things robust don't require particularly profound or cutting-edge technology. As long as you put your heart into it, you can do quite well.

Conversely, those who do poorly at work aren't necessarily bad at technology. People's evaluation of them is bound to be "irresponsible." As the saying goes, attitude determines everything, and the fruit of attitude is responsibility. Even if your technical level is average, if your attitude is serious and you're responsible, you're an excellent employee—and more valuable to the company. As for those who are technically strong but have a poor attitude and shirk responsibility, those are the types who just coast along eating and drinking, waiting to die—tumors that will be cut out sooner or later.

Becoming a professional code monkey

"Professional" here refers more to form and method—the way of doing things. Before explaining what "professional" means, let's look at some examples of what is unprofessional:

• During a phone interview, without asking whether the other party can hear you clearly, you start blah blah blah. After about ten minutes, the other party sighs and says, "Sorry, bad signal, I didn't catch that..."
• For example, during a phone interview, the candidate says, "Let me find a convenient place first." After finding one, they call you and say they've found it—and then the phone interview begins... on the candidate's outgoing call...
• For example, being late to meetings, or making small talk during meetings...
• Jumping to conclusions before understanding the full picture—especially for the hot-tempered—and even starting to curse people...

I believe examples like these are too numerous to list, and I'm also absolutely sure that we code monkeys and code fairies run into such things all the time in daily work. Our usual response to such things is "unprofessional"—yes, that's exactly what it is.

The reverse is professional:

Before the phone interview, first confirm whether the other party can hear you clearly, and then blah blah; when the candidate tells you "I'm free now, let's do the interview"—that's a notice. You hang up and then call them back; have a clear meeting agenda, don't be late; understand the full story before you start cursing... and so on.

"There is an order in learning, and every craft has its specialization." That's all there is to it.

Knowledge is endless. There will always be things you don't know, things you can't do. Even if you've been a code monkey for decades, known as someone who knows everything and nicknamed "Mr. Know-It-All," it's not hard to stump you—even a schoolchild has knowledge you don't. The software industry is divided into many fields. They say every trade is a world apart, but different fields within a trade also have gaps—for example, client-side, backend, frontend, drivers, game engines, graphics and imaging, security, and so on. So we must maintain a thirst for knowledge and a humble attitude. Even if you're a frontend big shot, when you encounter a driver problem, you're a noob—you have to learn humbly and ask others for guidance.

In addition, when interviewing, as an interviewer holding life-or-death power, you should show respect to candidates. Don't deliberately make things hard or "go through the motions of interviewing for your boss even though you clearly don't want the person" for non-technical reasons like the candidate's background (non-professional-track degree or associate degree), experience (small companies, outsourcing firms), lack of experience (few years, no standout projects), or mismatch (you need client-side, but most of their experience is frontend), nor look down on candidates for other reasons (I once met someone from a foreign company who looked down on people from domestic companies, saying that domestic companies just copy foreign ones). As the old saying goes, "Never employ someone you doubt; never doubt someone you employ." As an interviewer, you can pass on a person—that's your right—but you must respect them, even if their abilities really are lacking. Everyone has times when they bow their head. Is a foreign company so great? Aren't foreign companies in China just outsourcing arms of headquarters, doing all the odd jobs? Motorola was so awesome back then—great pay, super picky hiring—and now the tree has fallen and the monkeys have scattered! As the old saying goes, don't show off, or you'll get struck by lightning sooner or later!

How to stop the confused eyes and settle the restless heart

Whenever we feel lost, it's because we think too much about the future and do too little in the present; whenever we feel restless, it's because we expect too much and accomplish too little. No matter what you become or where you're headed, the key is to start from where you are now. You can't dream of flying straight there—there's no helicopter and no hot-air balloon that can lift you off the ground. You can only start from the present, stay grounded, and move forward step by step.

This is still a bit vague, a bit chicken-soup. Let me talk about how to do it concretely:

• First, figure out what exactly you do. Right, a code monkey who just writes code. Which layer's code? Android? Apple? Applications? Frameworks? Drivers? Which domain? Graphics and imaging? WebKit? Networking? Bluetooth? Finance? Security? What—you don't write code, you just maintain and fix bugs (quite a few people, for example those on turnkey Android solutions, only maintain and fix bugs)? Same thing—figure out which layer, which domain.
• Then, once you've figured out what you do, it's simple: do what you're supposed to do well, get thoroughly familiar with it, until you only need half a day to finish a full day's work.
  Writing code requires learning how to write code that is both good and fast—that is, being able to quickly complete specified requirements with few bugs. On a higher level, it also involves writing clean, understandable code with reasonable structure and clear naming. This is the cultivation of fundamental skills, and it has long been overlooked, because almost no company's KPIs involve whether code is good or bad; at most they cover the number of bugs, crash rate, performance, and stability. These are software metrics, not code quality. The best way to measure code quality is to see the reaction of the person who takes over your code—to see how many times they curse at you. For improving code skills, you can read books like "Code Complete" and "Clean Code," but more importantly, read excellent open-source code.
• Another is to become familiar with the existing codebase, striving to know which classes need to be modified and where to add new code whenever a new requirement comes in. When fixing bugs, you should be able to think and know roughly where the bug is, which class or method is causing the problem.
• Also, be familiar with business logic. Any software is created to implement business. To understand business logic, first understand the logic of the small module you are responsible for, then the business logic of the entire software. This is very beneficial for evaluating new requirements and solving bugs, as you will think from a holistic perspective. There are specific indicators, such as organizing requirement documents, and from them you can generate various test cases and scenarios, which helps you verify the correctness of your code.
• After that, prepare and back up common test environments, test data, and test cases. After new requirements and bug fixes, you should also organize and add them to the test repository for self-testing and regression. Although QA ensures software quality, our software should at least be working and meet requirements before it goes to QA. In short, professional programmers should do sufficient testing themselves. However, testing is sometimes not so convenient. For example, on the client side, it often happens that the backend data is not ready, so you need to mock data; some data only appears in rare scenarios, and you also need to mock them for testing; before release, you need to test in the test environment with a test server; etc. What this means is that if you frequently need these things—like mock data, proxies, etc.—you should invest some effort in organizing and backing them up, and even find ways—whether by writing code or using open-source libraries—to set up a convenient testing environment. This is very helpful for development. You might recall that a bug can be easy to fix but hard to verify, requiring proxies, mock data, simulating special scenarios, adjusting network environments, and so on.
• Also back up common environment configurations. For example, if your code has different customizations for different scenarios, the best approach is to make a copy for each scenario, with each one fully configured, rather than using different branches, even though that is also possible. There are two reasons:
  After a few years in the industry, we know well that environment configuration is also part of development, and it is usually very troublesome. It can turn something that looks like a ten-minute job into two days of work, and it still might not be done. Today's code is very complex, and the complexity lies not in the code itself, but in the extremely complex dependencies. People who often tinker with open-source software should know that a library itself may not be complex, but to use it, you need to install and configure a whole bunch of dependencies. Imagine, if you don't use a package manager (like apt-get, brew, pip, etc.), try manually installing OpenCV, or directly compiling its source code.
  • Although code branches can distinguish different code, environment dependency configurations are often not in the repo. This means that after switching branches, you still have to deal with environment configuration and dependencies.
  • Another reason is the issue of parallelism. Suppose you are developing a new feature on the branch for version A, and at this time version B (assume A and B are for different customers, and the two branches differ) requires a bug fix. Do you think it's more convenient to switch branches, or to work in another directory? I think the physical isolation approach is better.
• After achieving all the above, I believe the tasks within your responsibility will no longer be a problem for you. At this point, you need to study deeply and understand the things you depend on. For example, you use networking libraries like OkHttp and Retrofit—why are they better than the native ones? What are their main principles? What is their encapsulation philosophy? Similarly, for image-loading libraries like UIL and Picasso, what are their principles? The underlying libraries they depend on are very well encapsulated and easy to use. The more such libraries are, if you only know how to use them, then you're done for. Because even someone who has never used them can figure out how to use them after reading a tutorial for a few minutes. Only by deeply understanding the implementation details and learning advanced usage can you truly not have used these excellent libraries in vain.
• Furthermore, in any field and at any level, performance tuning is a hallmark of an expert. Performance tuning work on a project is usually handled by experts. So if you have studied and practiced performance tuning, it is definitely a huge boost to your skills, and it will be a big plus in interviews.
• Finally, be dedicated and take your work seriously. Take every line of code and every bug seriously. Even if you don't like your current job, even if you feel you're wasting time and life, fixing bugs every day with no joy, you must still take it seriously and do your job well. As the saying goes, "Take money and eliminate disasters for others." Since you receive a salary from the company, you should do your job well. If you can land a better job in the future, that's another matter, something for later. Today, while you're here, you must do what needs to be done. If you are overly impetuous, have high ambitions but low abilities, and always muddle through, do you think you can get a better job? Would the boss entrust you with more important tasks? Although the world is a strange place and indeed some people get higher salaries and better jobs not because of their skills, I believe in most cases it is proportional. People with better treatment than you have legitimate reasons. If you don't accept that, then you should work even harder. When you land a better job in the future, prove to others: "I am better than all of you!"

If you can do the few things suggested above and persist a little, within six months you will definitely see a qualitative change.

Fuck career planning and long-term plans.

Career planning is a methodological thing, even less reliable than fucking design patterns. Long-term plans are even more harmful. Plans exceeding one year, or even six months, are bullshit. Go ask those big shots—few of them have goddamn clear career plans and long-term plans. Their common traits are: they are good at digging deep, can chew through books, can read code, have active thinking, clear logic, and when solving problems, their approach is more elegant than yours.

Why is this stuff useless? Because in real life, things change really fast. Projects may be discontinued after a few months. As for people, Zhang San resigns today, and Li Si transfers to another position tomorrow. Before you finish, the requirements change, or this operation activity is canceled because the boss won't approve the budget...

Let me give a specific example from my surroundings: Last year, a new intern joined the team. He was hired as an Android client developer. After he arrived, he was assigned Android tasks in the first week. In the second week, a new major requirement came up that needed H5 (Mobile HTML5), so this kid had to do H5 (he had to learn JavaScript from scratch). After about three months, company policy changed, and they couldn't use so many interns, so the kid had to go back to school. If you were this kid, you couldn't even fulfill a one-month study plan, because you don't know what will happen next week, or even tomorrow.

To get a better environment for growth and learning, you need to go to a big company.

Whether to go to a big company or a small company can be listed as an immortal topic on par with the C vs. C++ debate, the GNOME vs. KDE debate, and the Vim vs. Emacs debate. I believe that when you are in the early stage of your career, such as just graduating or within two or three years after graduation, a big company is undoubtedly a very good choice. Here, "big company" includes top domestic companies such as BAT, NetEase, and other well-known large domestic companies, as well as large foreign companies like Intel, Microsoft, Facebook, Google, and so on.

Next, let me talk about the reasons. Companies hire us to get work done, to create value, and to help the company make money. They don't hire you to learn, to broaden your horizons, to get close to big names, or to discuss problems. A big company, because it is big, has a stable source of income and profitability, so its pace is regular and relatively relaxed. Its projects are either mature and stable, or not carried out for short-term profit. Therefore, it is deliberate in talent development. In other words, it can tolerate you learning, or even slightly slowing down your work tasks (I mean slightly slowing down), because the company also expects you to learn and improve your skills and abilities. The company will have the space to accommodate a better you. To put it plainly, there is enough room for you to improve and rise, and there is time and patience to let you complete this process. Can a small company have such space? Can it allow you to say, "I'll study for a few months first"? Maybe a few months later, when you return from your studies, the company might have gone bankrupt.

In addition, big companies have many people—more good people, more experts, but also some bad people and quite a few incompetents. You can meet more people, learn how a big company operates, what enabled it to grow so big, and how it keeps running without declining. In a big company, you can have time and space to learn, broaden your horizons, and expand your network. These are things a small company cannot provide.

In a word, when you are in the rapid learning phase of your career, a big company is the best choice. When you feel you have learned enough or have hit a new bottleneck, then a small company is a great place to put your skills to full use. So you see, people who come out of BAT, whether starting their own business or joining a startup, have a very good outcome. This is a win-win. For us, a small company offers more space, fewer people but more things to do, and is a big stage for you to show your abilities. And small companies precisely need such versatile people who can do the work of ten, being both CTO and code monkey, both developer and operations.

Communication and code maintainability depend on whether the author considers others.

If a person is willing to consider others and put themselves in others' shoes, I believe their communication skills will not be bad, and the readability of the code they write will not be too bad either. If you don't care about others, only talk for your own sake, and forget about it after you've said your piece, then no matter how you communicate, it won't work. If you don't consider that others will have to maintain your code, and don't even consider that you yourself will have to read the code you write now (see, you don't even consider yourself), then if such code is maintainable, then I've lived in vain.

To resist foreign aggression, one must first stabilize the interior.

The Generalissimo's saying is quite profound and meaningful, and it also has guiding significance. My understanding of this saying is that, from individuals, teams, and departments up to companies and countries, you cannot carry out two or more major things at the same time. Only after you have finished one can you move on to others. It's a bit hard to understand; let me explain slowly.

As the saying goes, "When you are well-fed and warm, lewd thoughts arise." When you don't even have your next meal, how can you think about picking up girls? When you haven't even learned one skill, one programming language, or one platform thoroughly, why think about cross-platform development, or breadth of technology? That's all bullshit. If you dig wells everywhere, none of them will be deep, and in the end you'll never dig up water in your lifetime. It's like saying ten 10% does not equal one 100%.

Another example is the team—every release turns into chaos. How can you talk about XP or technical innovation under those circumstances? Do the job of getting familiar with the technologies your business actually needs, and get them down thoroughly. First, do your own work well, and do it with ease. When you can handle every release effortlessly, or even when the work of 10 people can be handled by 5, then—and only then—is the time to pursue technical innovation, unit testing, XP, technology-driven culture, or an engineer-centric culture.

At the company level, when you haven't even secured a stable share of the market in your current domain, you copy others' grand strategies: they get into finance, so do you; they get into cars, so do you; they get into film, so do you. This will sooner or later kill you. Take Mr. Jia (Jia Yueting) today—of LeEco's TVs, phones, and sports divisions, which one has a stable market share? Which one can shoulder the responsibility of feeding the family? Yet he goes off playing strategy games and building cars? That's called "No zuo, no die." Mr. Ma (Jack Ma) is good at strategic layout, but he only did it when he had a monopoly in one domain: when he launched Taobao, it was because B2B had gained a solid footing and could support the family. In other words, B2B was already well-established, held the majority of the market share, and was profitable, so even if Taobao failed and lost money, it was no big deal. Later he launched Alibaba Cloud, and now the film division, Cainiao, Double H—all of these require continuous cash injections. Why? Because Taobao and Tmall can sustain the entire Alibaba, and even if all of them lose money, he can afford the losses.

The same applies at the national level: when people still can't get enough to eat or wear, how can you talk about spiritual civilization or technological innovation? For example, China in the 1970s and 1980s, or Southeast Asia a decade or so ago (the weaker countries, not the Four Tigers), and environmental protection—when humanity faces a choice between its own survival and environmental protection, it can only choose the former. So when a less-developed country is advancing toward a moderately developed one, economic development always comes first. The human development process is the same everywhere: pollute first, pursue development, then clean up.

At this point, I believe you understand what I mean.

Improve competitiveness to add value.

What is competitiveness? I think it means cultivating the ability to solve problems that can't be solved by just Googling. In plain terms, it's a knowledge system. A problem that Google can solve is necessarily a single point. Whether it's StackOverflow or a blog post, they always address a point problem—it can't be too big, because if it were, how could a single article explain it clearly? Multiple points, connected over time, form a system. This comes from repeated Googling over a long span, plus thinking and summarizing. That's competitiveness. That's also the value of an experienced veteran.

Many people debate: should you keep writing code after 30? What do you do after 40? It's true that as age increases, your body and energy decline, and you can no longer pull all-nighters like you did in your youth. So the situation for front-line workers in their 30s is quite difficult. The first few years after graduation are a period of rapid growth—as long as you're willing to study hard, your skills and income rise in a straight line. But for front-line coders nearing 30, getting straight rises in both skill level and income becomes quite difficult. Family, life, and physical condition leave you with less time to study. At this point, the things you can do are things that people just one or two years out of school can also do—and they have more energy and better health. So many people either switch to management or change careers entirely, and those who remain are always pondering when to make the switch.

In my view, the most important reason for this awkward situation is the failure to continue learning and the failure to build up enough competitiveness. Even if you don't become a manager or a top expert (in real life, it's impossible for everyone over 30 to become a manager or a master), if you keep learning and continuously improve your competitiveness, you will always be increasing in value—even if the company only gives you standard yearly raises.

When it comes to salary, we should calculate it on a per-unit-time basis. Suppose your monthly salary is 2,150 yuan; this is derived from 21.5 × 100. If you take one day off, 100 yuan is deducted. Converting further: 8 × 12.5 = 100, meaning your hourly wage is 12.5 yuan. Say two people both have a monthly salary of 2,150, but one person has a higher skill level: a day's work is done in 2 hours, and a month's work in one week. The other person has to work overtime every day just to finish. Whose salary is higher? Of course, this is a simplified scenario; real life is more complex. Although everyone has a rapid growth period, and companies also have periods of rapid expansion, eventually everything reaches a stable state. Stability means hitting a bottleneck. Take most people in big companies like BAT, for example—using Alibaba as an example, the vast majority of people stop after reaching P7. Getting promoted to P8 without being a manager is very difficult, and it only gets harder. So these people can only get standard yearly raises. To raise their income level, they can only increase their value by improving their own work efficiency.

Some might say this isn't realistic—work isn't necessarily evenly distributed, and veterans may get assigned more tasks. In fact, this decision lies with yourself. If you're already a veteran with no hope of advancement, why do more? This is an era where the behind decides the head—that is, an era where salary decides responsibility. How much effort employees put in depends on how much they're paid. To put it bluntly: they pay a fresh graduate's salary, yet expect you to do an architect's work and carry a CTO's responsibility. People only do that during the early career phase when they're learning and growing quickly—and once they feel they've learned enough, they immediately hop to a better position.

In short, only by continuously learning and summarizing, and by cultivating more competitiveness, can you become more valuable as you age.

Important matters don't necessarily have to be prioritized first.

When there are multiple big tasks at hand—for instance, a new feature, several bugs in the already-released version, and a technical proposal for next month's operations campaign—when all three are on the table, you can only choose the most important one to do first. This does indeed require applying the principle of important things first.

But suppose there are also some other small tasks to do: for example, topping up your phone; buying something online; upgrading a piece of software. These little tasks that can be done within 10 minutes are better done first. That way, your mind is clear and you won't keep thinking, "Remember to top up your phone." These small things are naturally easy to forget, so your brain subconsciously reminds you of them. This disturbs normal work thinking and affects mental focus, thereby reducing efficiency on important matters. Moreover, following "important things first" can result in these small tasks not being finished by the evening and being postponed to the next day.

The distinguishing principle is this: if a small task can be done within 10 minutes, then do it immediately. Understand that the shorter your to-do list, the better. As for those tasks that take half a day or a full day, they should of course still be handled according to the important-things-first principle.

Don't work hard overtime on business tasks; instead, work overtime to study.

Overtime is unavoidable in the software industry, especially the internet industry. In the current mobile internet era, 996 is a common phenomenon. You might feel fulfilled, you might feel a sense of accomplishment, or you might feel tired. But doing business tasks overtime every day like an ox is, at the very least, the most fatal thing for personal growth. Now that it's the end of the year, look back and think: what did you do this year? How did you grow? You'll find you did a lot of things, but grew very little. When you encounter something you don't know, you search online, copy it, and that's it. You did so much business work—do you feel a sense of accomplishment? A programmer's sense of accomplishment comes more from personal growth, from being able to do things that were previously impossible, not from moving bricks every day.

For instance, you know how to build houses. But if you spent the whole year building houses of roughly the same specifications, how much progress have you made? When a project to build a beautiful castle comes along, can you handle it? The company pays us to create value. For the company, houses are the value. As long as you can produce more houses, you're worth the salary they pay you. The day you get old or sick and can't build houses anymore, they'll immediately find a younger, stronger person to replace you. But how you upgrade yourself into someone who builds castles—the company doesn't care at all.

So, if you feel you're moving bricks every day—several months, or even half a year, with no progress, no new knowledge learned, and no real understanding of the problems you've encountered—then it's time to pay attention. Slow down the brick-moving pace. Even if it means sacrificing your KPI, stop and study, summarize, and think about how to do better. For example, for repetitive work, can you use scripts for things like packaging and releasing? For the requirements coming from product and operations, can you reasonably decline them? For repetitive operational campaigns, can you create configuration templates, and so on?

Working overtime on business tasks every day won't lead to progress. To progress, you can only study.

Learn to work smart.

When taking an exam, what's the best method? Not guessing blindly, not solving it yourself, but copying the correct answer. When a task is assigned, what's the best way? Not doing it yourself—even if you're already thoroughly experienced with it—but having someone else do it on your behalf. The most effort-saving, easiest way to get things done is to have someone else do it. There are many ways to accomplish something; we should choose the lowest-cost approach.

This isn't about encouraging everyone to be opportunistic and push your own tasks onto others—of course, if you have the ability to push tasks off and the other person is willing to take them, that's fine too. Rather, it's about working smart and not exhausting your energy on things that should be someone else's responsibility. For example, software dependencies are quite complex nowadays, and problems usually surface at the upper layer. If you discover the issue is caused by the underlying layer, then don't dig into it (unless you have ample time for study and research)—let the responsible person investigate it instead. They're more familiar with it. What might take you a whole day to figure out, they can solve at a glance.

Furthermore, for annoying manual operations and repetitive tasks, write scripts to finish them. The computer's greatest advantage is its ability to complete tasks repeatedly without making mistakes. Its greatest edge lies in repetition—humans aren't as good at repetition as computers, and they make mistakes, like typographical errors. Many things, such as packaging, releasing, and so on, can all be accomplished with scripts.

Learn to leverage the advantages of being a programmer.

Software is no longer that mysterious, hard-to-fathom thing from university labs. It has become integrated into people's lives—even seniors dancing in the square use smartphones, WeChat, and Taobao. I believe fewer and fewer people will ask software engineers to fix their computers. This means we deal with software every day and can't live without it. As people who know how to write software, we should make good use of our advantages. Let me illustrate with some examples:

• Be able to identify all kinds of phishing text messages and fraudulent calls/texts. If a programmer gets scammed by telecom fraud, you'd have to say that programmer is a colossal failure.
• For various software, be able to identify which one is genuine, which is a knockoff, which is fake, which might carry a virus, and which might have a Trojan. More importantly, have security awareness. Personal information leakage in mobile apps and websites is very serious nowadays, so pay extra attention to managing app permissions, and register on as few websites as possible. Besides watching out for your own information security, you should also remind the people around you.
• Another example: ordinary people get information by visiting websites and using search engines, but shouldn't programmers (猿媛) use crawlers?
• Another example is grabbing red envelopes, grabbing tickets, flash sales (don't go for mooncakes haha), boosting votes, boosting comments, and so on. Ordinary people rely on manual effort, manual work, and posting to their Moments. As programmers, we definitely have to rely on technology—writing a script, writing a piece of code to help us do these things. This is also an advantage that comes with our profession.

From: Wanderer's Starry Sky
Author: alexhilton
Link: http://blog.csdn.net/hitlion2008/article/details/54089376