The programmer's law of survival is listed here: programmer's law of survival-directory
If you prefer to start from scratch, you can move on.
------------------------------------------------------------------------------
1. Lost in "Bo" and "professional"Suppose that a person's learning has been focused, and the learning content is consistent with the project he or she actually participates in. Is there no problem? Unfortunately, the answer is still no. In any sub-field, we still need to consider the balance between "Bo" and "professional.
For software development, design is a more common and simple word. However, if we increase the angle of view, we will find that the design is still an exhaustive field. We can quickly scan some concepts related to the design:
Sometimes the methodology will also be involved with the design:
If you feel that this is not enough, you can go to wiki to query the paradigms entry, which lists 47 paradigms, each of which is somewhat related to the design.
The above is just about the design. If it is expanded horizontally, the selection of frameworks and the use of auxiliary tools will inevitably be involved in specific fields. This means that from the perspective of Bo, even in designing such a seemingly narrow field, there is still no boundaries.
At the same time, it is also a low-value group to thoroughly research an API, because this deep understanding is not much different from simply using an API from the perspective of creating value.
This means that for most software developers, they need to find the balance between broad and excellent species: neither close their eyes nor use a microscope to see the world. The value of this equilibrium point can be illustrated by the reverse Barrel Principle: the water in the bucket is determined by the shortest board, however, considering the value of a person is applicable to the anti-Barrel Principle, that is, the value of a person is usually determined by the longest board.
Considering Boundary and professional issues, you cannot leave Product Development for consideration. As mentioned above, product development is often more closely bound to the company's cash flow. technologies that can contribute to the cash flow are valuable technologies. In fact, product development has put forward the most basic requirements on the degree of knowledge and expertise. Such requirements are often iterative. Here is a general example to illustrate this point in an image:
In the first fall generation, we often need to achieve two basic goals. The first goal is to contribute to the product, but the code quality is normal. If this goal cannot be achieved, a person will lose his or her own value.
At this time, you need to know at least a certain language (such as C ++), a platform (such as Windows), an IDE (such as Visual Studio), and some business-related knowledge (such: print system ). This range can be as small as possible, but you need to learn it thoroughly. For example, regardless of the framework, you need to understand its memory mechanism, thread mechanism, exception processing component construction, and international processing mechanisms, rather than just understanding how an interface is used.
This is not a high requirement. Without this, it becomes "luck-based programming". After writing the program, pray that he can run it. After understanding this, you can afford part of the development work. Otherwise, you can only be a bystander and cannot participate in the actual work.
The second goal is to do things well and be able to afford higher levels of work. At this time, we need to have a deep understanding of object-oriented, structured methods, design patterns, and design principles, and make good use of them. At least we must be able to determine that this program is well written and that program is not well written. At the same time, we can continue our work as needed.
The first two goals are the foundation. Generally, the better the foundation in the school, the shorter the stage. After achieving these two basic goals, we can make further choices based on the situation. We can think that this is the second iteration in the selection of the experts and experts. Of course, remember not to separate it from practice at this time.
After completing the above two layers, you can choose from two directions.
The marginal effect is that you only need to invest 500 RMB for a single region to increase from 1000 RMB to 100 RMB; 1000 RMB for a single region to increase from 1500 RMB to 200 RMB; to increase the number of primary production from 1500 to 2000, 400 pieces are required.
A typical example is the study of C ++. c ++ is recognized as complicated. If you want to be a C ++ lawyer, it is estimated that you will be eligible for 10 years, however, the problem is that the input-output ratio may not be good if all the time is invested. It is a matter of scale. It is generally a matter of time-consuming details and is not suitable for the bottom layer. For example, for a 1 million-line program, it is a bit too much to take the time to understand every detail in advance.
When designing a solution, you must first consider whether to develop your own or use existing modules. Once you decide to use an existing module (package, framework, etc.), you need to further consider which one to use.
When doing this kind of work, without some extensive knowledge, it will be particularly difficult to make choices.
If the company wants to import a project management system, the decision owner must consider at least the following:
It is difficult for a person to master all of the above fields, but it is disastrous to have no concept at all when making a choice.
In addition, there seems to be a special case when considering the boundary and specialization points. People who study specific algorithms will only develop in the specialized direction from the very beginning, and will not consider anything else. For example, the study of TTS may take decades, for example, as long as you focus on TTS.
The specific direction should be determined based on the actual situation. The general principle is to take the current work as the foundation, select various knowledge for practical purposes, and pursue a balance point.
In general, it is expected that technical experts will be more suitable for the previous direction, while those who want to do technical management will be more suitable for the latter.
Timing and necessity of Learning Software Engineering
Simply put, people with less practical experience are not suitable for learning software engineering. The more you plan to grasp the overall situation, the more you need to learn software engineering.
The elements covered in software engineering are complex, including management, processes, development models, estimation, and analysis and design methods. This will undoubtedly expand the knowledge to a wide extent. Once there is no root cause, it will easily become a discussion on paper.
Among the numerous software-related knowledge, software engineering is definitely a very special one. Many people despise software engineering and say: As soon as I see a software engineering book, I skipped it. In contrast, many people highly recommend software engineering, I will spend a lot of time studying agility and cmme.
Programmers who have just entered the workplace hate software engineering because it is a little far away from their own practices and is mainly used to add constraints. However, since more complex and complex history can summarize the rules, ignoring the internal laws of software development is undoubtedly not good for those who are interested in becoming managers.
I really want to learn software engineering. It is not suitable for textbooks with a high level of abstraction, but for books that are closely related to the actual situation like code Daquan.
It seems that the implementation of software engineering in China is always difficult, and terms related to software engineering are constantly changing (ISO, cmme, agility, etc.), but there are not many practical applications, this eventually leads to a desperate situation: Just to despair, we began to report hope for a new one, and made an infinite loop on these two simple steps. This situation may be caused by a deeper level. For example, if the survival pressure is too strong, the long-term value of engineering power is ignored, and the methodology does not exist to solve practical problems, it exists for the certificate. It is difficult to say that software engineering has no value.
2. miss a good time in your life
Programmers who have not graduated or have just graduated often feel a lot of free time and are still worried about how to pass the time, but in fact, a person's life can be used to charge less time than he thought. Once you miss the opportunity, you will often regret it.
For most people, life is like a template, and there are deviations in small places, while the big places are basically the same.
20 ~ The 30-year-old can be said to be a golden age. In this phase, the family has a small burden and can be controlled for a large amount of time. Of course, a company that has hit a very special one and needs to work overtime can only be considered another.
After the age of 30, because of the birth of a doll, the family's time overhead increases, and the personal disposable time decreases. A large number of people may face the conflict between mother-in-law and daughter-in-law that is often mentioned in TV series, making you feel uneasy every day.
After the age of 40, family chores will be further increased. Typically, there are old and small families. If you are not lucky, you will also have some problems-cervical spondylosis, lumbar disc herniation, and gastrology can probably be included in the three major occupational diseases of programmers.
After the age of 50, the time will be relieved again, but unfortunately I am also old and the time is not there.
If you draw a parabolic line of life by age, the point of life that a person in his or her 40 years old can reach will decrease the chance of making another breakthrough in the future. From the perspective of historical figures, it seems that there are very few things late.
After careful observation, you will find that the recruitment revelation often indicates that you are under 35 years of age or under 40 years of age, unless you are a senior recruitment officer. This, in turn, means that if you do not reach the top level, your life will be finalized before 40, and then there will be a risk of decline (such as a slump, company collapse, etc ). For programmers, this risk is especially high, because it is very likely that the knowledge system you have learned has been replaced.
Learning needs to adapt to this natural law.
A big mistake for many people is that, in the golden age, they have to enjoy life without accumulating anything. Once they realize the necessity of accumulation, in the end, my life was very limited, and I quickly fell down. This is the modern programmer version of the "Little strong do not work hard, the boss is sad ".
Basically speaking, before the age of 35, you need to master the skills that took a lot of time and were relatively hard to learn, steep learning curves, and all the major skills required for work, after the age of 35, I focused on updating knowledge and some soft skills.
The tactical efficiency of adding water to learning is really poor. Every time a match is clicked to boil water, 0.1 billion years of water will not open a pot. At the same time, relatively hard skills (such as Donald knuth's "computer programming art") often require a large amount of time investment, but the older the time, the more fragmented, the harder it is to deal with hard knowledge-the more natural it is to create water tactics. Soft skills can be learned by means of fragment time, for example, improving the PPT production level and presentation ability.
If you can arrange your own time and the relationship between hardware and software knowledge, you can accumulate on a specific basis and make small strides forward to increase your value. From this point of view, young people are definitely a kind of debt. Most people must pay off what they owe before they finish completely.
So specifically, those things are hard and should be done before the age of 35? This varies with goals, but the following projects should be highly universal:
The time and necessity of learning English
In general, the programmer's learning English is a relatively good investment in return on investment. From the perspective of the goal, programmers may not necessarily be fluent in spoken English, but at least there is no obstacle to reading English documents. There is a subtle thing here. Once the English reading problem is too high, you will get used to Baidu to find the problem, which naturally limits a person's vision. It doesn't mean that Baidu itself is poor, but that the English-speaking world has more and more exciting content. Whether we like it or not, we must admit that English is a world language in the IT world. On the one hand, it is because of the strength of American companies and on the other hand, it is because open source chose English. This eventually leads to new trends in the IT world, tips for solving problems, and website architecture. In stackoverlow, it is easy to find answers to various small questions, and in Quora, it is easy to find the architectures of various websites.
From the perspective of study time, this should be done in college. If not, at least one graduate will be required ~ Within two years, reading is not accessible. Of course, you still need to pay extra to join a foreign company. From the perspective of learning methods, there are no special tips for learning a foreign language. Just stick to it and invest time.
3. Stop updating knowledge
For the value-added programmer, the biggest trap in life may be to deceive the illusion of security and completely relax yourself. This situation does not happen in a harsh environment, but it is easy to breed in a monopoly enterprise or a leading enterprise in a certain field. It is not difficult to find out whether you have stopped updating your knowledge. For example, if you haven't read a book in a year, you have no new knowledge in a year, and your work load is not enough in a year, you can all become a signal.
This is really a warm boiled frog. once it reaches the age of thirty and gets used to it in this environment, it is basically impossible to jump out again. The only thing that can be done is pray that the company should not go down, and the company should not come to the game for a big change of people. Confucius said: it is necessary to know what to do after knowing the dangers.
After getting into a new position, you have to go through a process of learning and gradually becoming competent. In this period, most people have a high learning enthusiasm. Once you are competent, things will change.
A large part of people may feel that they will use such knowledge at work and will not be able to learn other things. Therefore, they began to close themselves up, not reading books, not reading technical news.
This is actually very dangerous, because it is equivalent to binding yourself to the current job. Every product has its own life cycle. Once a product's life cycle ends, it may happen that the technology it uses is outdated, and the parties will be embarrassed. Because the product can end, the life has to continue.
The most classic example here is MFC. Microsoft has a long history of this product. It has been around for nearly 20 years since its release in 1992 to 2012. With the advent of programmers in the 90 s, this technology will soon become older than programmers.
Even today, many desktop applications are still developed based on MFC, which can be easily verified by viewing the DLL dependency of the package. MFC is a large pool with depth and history. It takes a little time to figure out the class inheritance relationship, message mechanism, framework structure, rtti, and serialization of MFC.
Now we assume that a large enterprise application is developed based on MFC. A programmer has also learned about MFC through several years of hard work, learned about the application itself, and can afford bug fixes, new Function appending and other tasks.
Next, this programmer seems to have nothing to learn. Because the update of MFC has almost stagnated, it takes almost no time to learn it. The existing code is also clear, and it does not need to take a lot of time to learn. The existing procedures also meet the needs of enterprises, and there is almost no possibility of re-engineering.
So this programmer does not need to learn at this time? The answer must be no.
There is a big conflict in it.
From the enterprise perspective, a team is required to maintain the development of this program. But from an individual's perspective, if we spend all our youth on old technologies, what should I do if old technologies exit the stage of history?
In the above example, we assume that a person is continuously engaged in such development. When he is 45 years old, the current product lifecycle is over, and the world is only changed to mobile development and cloud development, so where should I go if I am only good at MFC?
If this is the case, this person will be forced into the dead corner, and his life may fall sharply. Therefore, you must not consider that you have learned enough to stop updating and learning your skills.
From the specific countermeasures, we should refer to the map of knowledge to expand the breadth of knowledge horizontally. For example, we should not only look at the code, but also understand the business. We should not only focus on development but also on estimation; the second is to improve the mastery of things with good mobility, such as object-oriented analysis and design, so that the transition to other technologies can be relatively smooth. Third, we need to strive for rotation and various practical opportunities.
Most people have agreed that managers need to understand technology. Logically speaking, "Understanding" is basically the premise of no command. Therefore, it can be called the "onsite" of the Chinese version. It is estimated that there is little controversy.
The key question is to understand to what extent?
If two people choose the management direction and the technical direction. The next step is to require that the technical level of the management team should be the same as that of the technical direction, so unless this person is especially talented, it is unlikely. As mentioned above, this is caused by the different "keys" in these two directions.
If you set the goal to ensure the success of the final product, and assume that the manager has higher decision-making power, the manager must have a technical sense in the following aspects.
From the product perspective, there are two key dimensions to be successful at the same time. One is to grasp the conceptual integrity of the product; the other is to use appropriate means to implement the product.
The previous topic was very old and mentioned in the Mythical man-month, but it was always forgotten in practice. A good product must carry out a unified will, and the iPhone re-verifies this old principle. Although the mechanical patchwork product integrates the ideas of many people, it is often mediocre and often the root cause of errors during project implementation. It seems that although there is law, everyone has his own understanding and does his/her own thing. This conceptual integrity is the first thing that managers need to be certain about, and the second is how to build products. To achieve this goal, managers must have their own understanding and at least have their own principles in the following aspects:
The following briefly lists several key considerations, which overlap with the previous discussion on how to develop towards BO:
Let us assume that some people do not think so. But after management, they show enough inertia and do not constantly update their knowledge systems. What will happen?
At this time, it is very likely that the management will be inverted. That is to say, managers are nominal superiors, but they basically lose their grasp of the scene. All decisions depend entirely on subordinates. Effective subordinates are not present, and various decisions can only be made by blind people. Eventually, they become managers who only communicate with each other. Even if they are eaten by diners, no one will notice that the value of existence has been infinitely diluted, it becomes a symbolic symbol. There may also be fierce conflicts with subordinates. Because such managers do not have their own positions, there are tasks that can only be under pressure. The results deviate from the actual situation by a thousand miles and are not reproducible. Such managers cannot state their superiors, so they can only shift down the pressure.
No matter what it is, once it reaches this level, it actually tends to fail and can only pray that the diners do not come.
Why should middle-level managers keep updating their knowledge?
There is a famous joke about diners in the IT industry:
Two diners apply for a job in a large company, and the company's personnel director knows that these two groups eat people every day, so he warned them: "If you dare to eat a person at the company, you will be fired immediately!" The two diners promised to never eat at the company. Two months later, the company was safe.
Suddenly one day, the company found that the cleaners responsible for cleaning the company were gone. As a result, the personnel director was very angry and found two diners angry and fired them on the spot. Out of the door of the company, a Diners immediately complained to the other: "I have always warned you not to eat people who are doing things. You just don't listen! We had a manager every day for two months, and no one found it. Now you see the cleaners, and they will soon find out! You are really a pig !"
The joke is that some big companies are suffering from a serious illness. It is difficult to explain the causes of major enterprise diseases clearly at once, but the results are obvious, which will certainly lead to many middle-level managers. If a successful enterprise is naturally infected with major enterprise diseases, then undoubtedly middle-level managers also naturally have a tendency to expand. From a personal perspective, it is not a good thing to become an experience that has been eaten by the fool, because it means that the value of existence is diminished, and there is no need to update any knowledge. In the face of layoffs, this person is likely to lose the ability to face brutal competition.
------------------------------------------------------------------------------
For my own information, you can find it on the left bar. If you want to know whether the person who writes this series of articles is a liar or a fool, you can view it.
In the end, I hope to support v Public investment. I feel that this is the most reliable Q & A community in China. It is the answer that a friend gives to his friends. At the same time, I will implement one person, one person, and one person, for the one-person-one-vote system, follow the public account: vzhongtou (with a QR code on the left.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
