The five major differences between top programmers and ordinary programmers

1. The courage to study the code you do not understand the general people do not want to study their own contact with the code, many people have not tried to give up. If you often study code that you have no contact with, you will become more familiar with different code structures and design patterns. Now it is easy to get access to excellent Open-source source code resources, you can easily download down to do some changes or debugging, to study why the code can write. In addition to the code, many people are afraid of unfamiliar job content. Every time you change your job, you may encounter a new company that has a different job description than the previous job, so that you're not as productive as you used to be at first. A lot of people even think that you cheated the interviewer. In fact, we are all in the process of learning. In a strange field, no one is the great God from the beginning. If you want to get better, whether it's writing code, communicating with people or other skills, you need to invest time in learning.
2. Proficient in code debugging (debug) Many people in the process of writing code, often have a problem is: why I write out of the code can not run. Why the result of running is not what I want. Almost all programmers write code that is not written all over again. But the top programmers are quick to understand what the problem with their code might be. This is a very important ability, but the school does not teach, interview when the examiner does not often mention. So how to debug the code. In fact, the core is the following methods: may wish to first guess what happened. Assuming your guesses are right, think about what your guesses will lead to the outcome of the program. Try to see if there are any abnormalities in these results. If you don't see the strange, then your guess is right. If you find something strange, then your guess is wrong and then try another guess. For top programmers, the process is a flash of lightning in the mind. As long as you solve enough problems, the more accurate your guesses will be. As to how to find strange. You need a set of tools or methodologies. The easiest thing to do is to output the log in the code to judge. But it's a stupid way to get in touch with some advanced tools or editors that have the debug function directly.
3. Pay attention to tools that can save time the recent defeat of human Alphago can be played in millions of chess training every day, we human 10,000-hour training but it takes 10 years. In other words, a computer running for a few minutes may be equal to a few years of human work. Bobby Johnson, a former technology director at Facebook, described the efficient programmers as spending their time on making tools. Many people also think that tools are important, but they don't take the time to make and integrate their own tools. But the Jonson team's best employees spend 1/3 of their time on tool making, which can be used to release code, monitor systems, and give them less time to do more things. In short, don't take the time to do the things that machines can do instead of you.
4. Optimizing your iteration speed assumes that it takes you 12 seconds to find out where a function is defined. Assuming you do this 60 times a day, you'll need to spend 12 minutes a day searching for a function definition. If you use a better editor, each time you find a function definition for just 2 seconds, you'll save 10 minutes a day. You can save 40 hours a year. If you can find 3 such scenarios to optimize, then you can save one months a year. Think about how many meaningful things you can do over the one months. And if you're debugging an app bug, you'll need to restart the app once you've changed the code, and then click 4 or 5 times to see if the bug has changed. So can you just take a few minutes to set the following up and let app go to the page that shows the bug as soon as it starts? Do not underestimate these trivial details, improve their return is huge.
5. Systematic thinking when you are writing code, it is easy to assume that as long as you implement the specified function as required, your code will be finished. But this is actually just the tip of the iceberg. Any code that is not published to the production environment will have no value whatsoever. If you want to write really powerful code, you need to understand your work from the whole system: what is the functional relationship between your code and the code that other people write. Have you tested your code well? Or whether someone else can easily test your code. In order to deploy your code, the code for the online production environment needs to be changed. The new code will not affect the code that is already running. Under the new features, your target user's behavior is not what you expect. Your code has no commercial impact. These questions are not easy to answer, but when writing code, you need to know if your code will end up with the best results.