1. "Bo" and "special" on the Lost
Suppose that a person's study has been focused, and the content of the study and their actual participation in the project also coincide, then there is no problem? Unfortunately, the answer is still no, in any one sub-field, still need to further consider the "Bo" and "professional" balance.
For software development, design is a common but simple word. But if you look at the point of view, it will be found that the design alone is still an endless field, we can quickly scan and design related parts of the concept:
- Object-oriented Analysis and design
- Structural Analysis and Design
- Model-Driven development
- Contract-type programming
- Aspect-oriented development
- Component-based development
- Meta-programming
There are times when methodologies are involved with design:
- Test-driven development
- Agile Software Development
If this is not enough, then you can go to the wiki to check the programming paradigm (paradigms), which lists 47 paradigms, each of which is somewhat related to the design.
These are just the design, if the horizontal expansion, then in particular areas will inevitably involve the selection of the framework, the use of auxiliary tools and so on. This also means that, from a Bo's point of view, even in the design of such a seemingly narrow area is still no boundaries.
At the same time, the re-penetration of an API study is also low-value people, because this deep understanding and pure will use an API, from the point of view of creating value, the difference is not small.
This means that for most software developers, there is a need to find a balance between broad and refined: neither close your eyes nor look at the world with a microscope. The value of this equilibrium point can be explained by the anti-cask principle: The cask principle is that the water in the bucket is determined by the shortest piece of the board, but the value of the person is applied to the anti-cask principle, that is, the value of the person is often determined by the longest piece of board.
Considering Bo and special issues can not leave the product development considerations, as mentioned earlier, product development is often tied to the company's cash flow tighter, can contribute to the cash flow of the technology is a valuable technology. and the product development itself in fact to the level of Bo and the most basic requirements, this requirement often has iterative characteristics. To illustrate this image, here is a general example to illustrate:
In the first fall, it is often necessary to reach the two most basic goals. The first goal is to be able to contribute to the product itself, but the code quality is common. If this goal is not reached, a person loses his or her existential value.
At this point, you need to know at least one language (e.g. C + +), one platform (e.g. Windows), one IDE (for example, Visual Studio) and some business-related knowledge (e.g., the printing system). This range can be as small as possible, but it needs to be learned thoroughly. For example, regardless of the framework, you need to understand its memory mechanism, threading mechanism, exception handling component building and internationalization processing these global mechanisms, rather than just understand how an interface is used.
This is not a very high requirement, and without this it becomes "programming by Luck", and after writing the procedure, I pray that he can run. Understanding these can be a part of the development work, otherwise it can only be bystanders, unable to participate in the actual work.
The second goal is to get things done and to be able to work at a higher level. At this time, we should have a more in-depth understanding of object-oriented, structured methods, design patterns, understanding design principles, and to use them well. At least to be able to determine that the program is written well, the program is not well written, at the same time to face the need to carry out the work.
The first two goals are the basis, generally speaking, the better the foundation plays in the school, the shorter the stage. By achieving these two basic goals, you can combine situations to make further choices, which can be thought of as the second iteration of Bo's choice. Of course this time also remember not to separate from practice.
After completing the above two levels, there are two directions to choose from.
- It is possible to further consider specialized issues, such as deepening knowledge in specific areas. Do drive to understand the core mechanism of the operating system, do the printing to understand the page description language, etc., but this time to properly guard against marginal effects.
The marginal effect is that you let an acre of land from the per MU 500 pounds to 1000 pounds may only need to invest 100 yuan; to increase the per mu from 1000 to 1500 may require 200 blocks, and to increase the per MU from 1500 to 2000 requires 400.
A typical example is the study of C + +, C + + is recognized as complex, if you want to be a C + + lawyer, then the estimated 10 years may be enough to qualify, but the problem is to put time on this, the input-output ratio may not be good. And stopping there is a scale problem, which is roughly a matter of time to compensate, and not for the very bottom. For example, for a 1 million-line program, it's a bit too much to take the time to get to know every detail beforehand.
- You can take a step further, such as knowing the expertise of a specific field, being familiar with the features of a variety of existing frameworks, and being familiar with the key points of improving the user experience. The specific meanings of the features that are familiar with the various existing frameworks are:
The first thing to consider when designing a solution is to develop or use existing modules. Once you decide to use the existing modules (packages, frames, etc.), you need to consider the exact use of that.
When doing this kind of work, if there is not a certain breadth of knowledge, making choices will be particularly difficult.
If the company is to import a set of project management system, then the decision-holders must consider at least all of the following things:
Do you start from scratch, or do you develop two times with ready-made? Are you using open-source products, Microsoft or other companies? With Microsoft, is MS Project or SharePoint, or hybrid? Is it really worth considering the cost of license? With open source products, are there so many options to actually import that one? If you build it from scratch, is it based on Microsoft technology, or is it based on a technology like lamp? What frame is used? If you want to do it, in what language? It is difficult for a person to master all the above fields, but as a choice, there is no concept that is catastrophic.
In addition, there seems to be a special case when considering the Bo and the special balance point, the person who delve into the specific algorithm, from the beginning only went to the specialized direction, does not consider other. For example: People who delve into TTS, may be decades as long as the focus on TTS is over.
As for the specific choice of that direction, it depends on its own situation. The general principle is to use the current work as the foundation, to select all kinds of knowledge for practical purposes, and to pursue a balance point.
Generally speaking, expect to be a technical expert is more suitable for the previous direction, and the expectation of technical management is more suitable for the latter direction.
the time and necessity of learning software engineering
simply speaking, the less practical the more people are not suitable for learning software engineering, the more need to plan the overall grasp of the global time the more need to learn software engineering.
Software Engineering covers a very complex element, can have management, process, development model, estimation, analysis and design methods. This will undoubtedly expand the breadth of knowledge, once there is no foundation, it is easy to become armchair, rhetoric.
In many software related knowledge, software engineering is definitely a very special one. Many people despise software engineering, said: I see the software engineering books directly skipped, and corresponding to, many people are highly respected software engineering, will spend a great deal of thought to study agile, CMMI and so on.
programmers who have just entered the workplace hate software engineering in general, because it is a bit far from their practice, and is mainly added to the shackles. But since more complicated history can summarize the law, ignoring the inherent law of software development is undoubtedly unfavorable to those who are interested in becoming managers.
really want to learn software engineering, not very well from the abstract high-level textbooks began, and suitable from the "Code encyclopedia" and so closely related to the actual book began.
in the domestic software engineering seems to always be difficult to the ground, software engineering related terminology has always been changing (iso,cmmi, agile, etc.), but the actual can fall into effect but not much, which eventually led to a paradox of the situation: Just a desperate, began to a new newspaper with Hope, And do an infinite loop on both of these simple steps. There may be deeper reasons for this, such as the fact that the stress of being too strong leads to the neglect of the long-term value of engineering forces, which makes the methodology not exist for solving real problems, but for certificates. It's hard 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 from the programmer often feel more free time, but also very distressed do not know how to kill time, but in fact, a person in life can be used to charge much less than the time to think. Once you miss the opportunity, you often regret it.
For most people, life is like a template, small and biased, but basically the same in large places.
20~30岁 This stage can be said to be the Golden age, this stage, the family burden is small, can freely dominate time more. Of course, bumping into a very special company that needs to work overtime can only be counted separately.
After the age of 30, because of the birth of the doll, the family's time overhead increases, the personal disposable time becomes less. A large part of them are also very likely to face the TV drama often said-law contradictions, let you unsettled every day.
After the age of 40, family chores are further increased, typically on older and smaller. Really bad luck himself will also have some disease---cervical spondylosis, lumbar disc protrusion, stomach disease can probably be selected as the three major occupational diseases of the program.
After the age of 50, time will be free again, but unfortunately, he is also old, the time is not.
If the life according to the age to draw a parabola, the 40-year-old or so a person can reach the apex of life, the probability of further breakthroughs will be smaller. Judging from the historical figures, bloomer is not without, but really very few.
Careful observation will find that the recruitment revelation often indicates that the age must be under 35 years old or under 40 years of age, unless it is a senior recruitment. This, in turn, means that if you don't get to the top, life will be stereotyped before 40, and then there are downside risks (such as recession, company failure, etc.). This is particularly risky for programmers, because it is likely that the knowledge system you have worked on has been changed.
Learning itself is undoubtedly the need to conform to this natural law.
A lot of people a big mistake is that in the Golden age, do not accumulate, to enjoy life, and once aware of the need to accumulate, but also trapped in a lot of trivial and want to vibration, eventually life is very limited, and quickly lower. This is the modern programmer version of the "An idle youth, needy age."
Basically, 35 years old before the need to spend a lot of time, relatively hard skills, learning curve skills mastery, with all the major skills required to work, and after the age of 35 is mainly concerned about the renewal of knowledge and some soft skills.
Learning to add water tactical efficiency is really poor, every time a match to boil water, 100 million years, also can not boil a pot. At the same time, more hard skills (such as Donald Knuth's "computer Programming art") often require large chunks of time to put in, but the older the longer the more fragmented, the more difficult to deal with the hard knowledge---innate easy to create Tim water tactics. Relatively soft skills, you can use fragmentation time to learn, such as: improve the production level of PPT, improve the ability to express.
If you can arrange your own time and soft and hard knowledge of the relationship, then you can build on a specific basis, small steps forward, so that their value is more and more high. From this point of view, Young is definitely a debt, and most people have to pay off what they owe before he is completely finished.
So specifically those things are relatively hard, to be done before the age of 35? This varies by goal, but the following projects should be highly versatile:
- Proficient in one of the most commonly used languages
- Learn about the basic mechanisms of one of the most common platforms, such as memory management, threading mechanism, etc.
- UML diagram and object-oriented analysis design method
- Design principles, such as: single duty, etc.
- Design Patterns
- Everything in the Code encyclopedia.
- The intensive reading of a well-known but somewhat-sized program. This is thanks to the Open source project for providing us with so many excellent programs. But beware of the ambitious, challenging the Linux kernel, intensive reading is the key.
- Accumulate a certain amount of code, such as: Independent complete did a tens of thousands of code line of things. The key here is to completely build your own, so don't copy and paste.
- Master basic Algorithms and data structures (you can not write it yourself, but at least know its complexity and differences)
- Develop a clear coding style
- have their own professional (finance, high-concurrency website, image processing, TTS, etc.)
the timing and necessity of learning English
on the whole, programmers learning English is a relatively good return on investment. From the target point of view, the programmer may not necessarily have to speak fluent, but the minimum to achieve the level of reading English information without obstacles. There is a subtle thing, once the English reading problem is larger, find the problem will be accustomed to use Baidu, which will naturally limit a person's vision. Not to say how bad Baidu itself, but the English world has more and more exciting content. Whether you like it or not, we must admit a reality, in the IT world, English is a world language, on the one hand because of the strength of American companies, on the one hand, because open source chose English. This ultimately leads to new trends in the IT world, tips for solving problems, the architecture of the site, and so on to the English-speaking world. In Stackoverlow it is easy to find answers to small questions, and in Quora it is easy to find the architecture of various websites.
from the time of study, this thing should be done in college, if not at least in the 1-2 years after graduation to reach the level of dyslexia, of course, want to join a foreign company also need extra pay. From the perspective of learning, learning a foreign language really no special tricks, adhere to and invest time.
3. Stop Updating knowledge
For programmers, the biggest pitfall in life may be to completely relax themselves by deceiving the illusion of security. This situation is not very likely to occur under the circumstance of poor living environment, but it is easy to breed in enterprises with absolute leading in monopoly enterprises or in a certain field. It is not difficult to find out whether or not to stop updating the knowledge, for example: A year a book did not see, a year a little new information is not in touch, a year of basic dissatisfaction with the workload can become a signal.
This is really warm boiled frog, once to more than 30 years old, and in this environment to stay accustomed to, then want to jump out, basically no possibility. The only thing to do is to pray for the company not to hang up, the company also do not come to a campaign, to carry out a large exchange of personnel. Confucius said: "When provinces, this is very necessary, as for the understanding of the danger can do something, it is there is nothing."
- Knowledge update of technical personnel
After contacting a new post, it is generally going through a process of learning and becoming competent, and most people have a high level of enthusiasm during this time period. Once you have the basic competency, things change.
A large part of the people may feel, anyway, the work is also used in all these knowledge, learning other also can not use, so began to shut up themselves, not too reading, not too look at technical news.
This is actually dangerous because it is tantamount to tying myself to the current job. And any product has its own life cycle, once the end of the life cycle of a product, it happens that the technology used is outdated, then the parties will be very embarrassed. Because the product can end, life still has to continue.
A very classic example of this is MFC. Microsoft's product has a very long history, with nearly 20 years of release from 1992 to 2012. With the gradual emergence of programmers, the technology will soon become older than the programmer's age.
Even today, many desktop applications are still developed based on MFC, which can be easily verified by looking at the DLL dependencies of the package. MFC is a large pool with depth and history. It takes a little time to figure out the MFC's class inheritance, message mechanism, frame structure, RTTI, serialization, and so on.
Now we assume that a large enterprise application is based on the development of MFC, a programmer also through a few years of effort to understand MFC, understand the application itself, and can afford bug fixes, new features such as additional tasks.
Then the programmer seems to have no learning to learn. Because MFC's updates are almost stagnant, it takes almost no time to learn from MFC. The existing code is also clear, and does not need to spend a lot of time to learn. The existing procedures also better meet the needs of enterprises, the possibility of re-starting is almost no.
So this time the programmer does not need to study? The answer must be negative.
There is a huge contradiction in this.
From an enterprise point of view, it must be a team to maintain the development of this program. But from a personal point of view, if all the youth are spent on the old technology, then once the old technology exits the historical stage, where should individuals go?
Or the above example, assuming that a person continues to invest in this kind of development, when he was 45 years old, the current product life cycle end, the world is only mobile development and cloud development, then only good for MFC he should go?
If so, this person is forced into a corner, life is likely to have a huge slide. So you must not think that you have learned enough to stop the renewal and learning of skills.
From the concrete response measures, one is to refer to the knowledge map, horizontally expand the breadth of knowledge, such as not just stare at the code, but also to understand the business; not only focus on development but also focus on a bit of estimation; This allows for a more gradual transition across other technologies. The third is to strive for rotation of jobs, to strive for a variety of practical opportunities.
- Knowledge update of Managers
So far, most people agree that managers need to know the technology. Logically, "understand" is basically not backseat premise, so this can be called the Chinese version of the "field doctrine", it is estimated that the controversy is not big.
The key question is, how far do you want to "understand"?
If two people, one chose the direction of management, one selected the technical direction. The next step is to ask the people in the direction of management the same level of technology as the technical direction, so unless the person is particularly gifted, it is unlikely. As previously mentioned, this is due to the difference in the "Key" in these two directions.
If the goal is set to ensure the success of the final product, while assuming that the manager has higher decision-making power, then the manager must have the technical feeling in the following areas.
From the product perspective, to succeed, there are two key dimensions need to grasp at the same time, one is the concept of product integrity grasp; one is to use the appropriate means to achieve this product.
The previous topic is very old, "People's Month myth" is mentioned, but in practice is always forgotten. Good products must carry out a certain kind of unified will, the IPhone, and re-verify this old principle. Mechanical patchwork of products, although a lot of people's ideas, but often mediocre, and in the project implementation process, is often the source of error. Very much like though there are laws, but everyone has their own understanding of fragmentation such a state. This concept integrity is the first thing managers need to be certain, and the second is to solve the problem of how to build the product. In order to achieve this goal, in the following aspects, managers should have their own understanding, at least to have their own principles:
Here are a few of the more critical considerations, which are somewhat overlapping with the previous discussion of how to move towards Bo:
Use existing products or develop yourself for example: those modules are good for you and those that buy. When you buy, you should follow the criteria to choose. The use of that platform technology, such as using Microsoft's technology, or open source technology. Whether the current structure can achieve product goals such as: the number of concurrent hardware plus software can support concurrently. How code maintainability Constrains this requirement must be mastered by some principled things, such as: What information is hidden, orthogonal decomposition, abstraction is sufficient, etc. And some non-ambiguous indicators, such as: cyclomatic complexity, Unit test income balance. Those links have to be solidified into processes, which must be free for the team to decide what degree of documentation is appropriate and what is required for input and output between different phases. ... ...
Suppose that some people do not think so, but after doing the management, showing enough inertia, no longer continue to update their knowledge system, then what will happen?
This is likely to be managed upside down. That is, the manager is the nominal superior, but basically loses the grasp to the scene, all decision-making completely relies on subordinates. Competent subordinates are not, all kinds of decisions can only rely on blind, eventually become only communication managers---even eaten by cannibals will not be noticed, because the existence of value has been infinitely diluted, became a symbolic symbol. There may also be violent clashes with subordinates. Because such managers do not have their own position, the above task can only be under pressure. The results deviate from the actual situation, and do not have the achievable, such managers can not speak to their superiors, but also can only move downward pressure.
No matter what kind, once to this point, in fact, tend to fail, can only pray to the cannibals do not come.
Why do middle managers insist on renewing knowledge?
There's a famous joke about cannibals in the IT industry, which says:
two cannibals recruited into a large company, the company's personnel officers know that the two men eat every day, and warned them: "If you dare to eat a person in the company, you will be fired immediately!" "The two cannibals only have a way to agree, said never to eat people in the company." Two months passed and the company was safe.
suddenly one day, the company found that the cleaners responsible for cleaning the company disappeared. So the personnel director very angry, to find two cannibals scold, and fired them on the spot. Out of the company door, a cannibal immediately complained to the other: "I have been warning you not to eat people who do things, you just don't listen!" We ate a manager every day for two months and no one found out. You see, now you eat the cleaners, they'll find out right away! You're such a pig! "
The joke is mocking the big corporate overstaffing of some big companies. The cause of large enterprise disease is difficult to say clearly, but the results are more obvious, will lead to more people become middle managers. If the success of the enterprise naturally infected with the trend of large enterprise disease, it is undoubtedly the middle managers also have a natural expansion trend. From a personal point of view, being eaten by ogres is not a good thing, because it means there is less value and no need to update the knowledge. Once faced with layoffs, this person is likely to have lost the ability to face brutal competition.
The law of the programmer's survival--a common pit in the growth path
