I forgot where I saw it and kept it on the hard drive, which makes sense.
1. Choose some useful techniques in a small area, learn them thoroughly, and embrace them. Then continue to expand this range.
2. Understand the advantages and disadvantages of various data structures, including their respective performance in memory and on the hard disk.
3. Understand the advantages and disadvantages of various algorithms.
4. Know your field of work. Turn off the computer and do what your users are doing.
5. Be prepared, have the desire, and have the ability to invest in multiple technical levels at any time. You must know the technical principles under the surface. There is a close relationship between "mastery of all technical levels" and "programming ability".
6. Use your imagination. Always ask, "Is there a better way?" Perhaps the best solution has not yet been discovered.
7. Excellent programmer: I optimize the code. Better programmers: I design data. The best programmers: What are their differences?
8. Structure your data correctly. Any defect will cause endless technical debt in your code.
9. Name things correctly. Use the "verb-adjective-noun" format to name programs and functions. The variable name should be long enough, as short as possible, and meaningful. If other programmers are unable to understand your code, it means that you did not write clearly enough. In most cases, coding for the next programmer is more important than coding for the environment.
10. Separate analysis and programming. They are not the same kind of things, require different types of labor resources, and need to be done separately at completely different times and places. If you do them at the same time, you will not be able to do the same. (I like to do analysis that does not involve technology at the end of the day, but to program the next morning.)
11. Never attempt to approach the road with ease. Never deploy the same code twice. Never name a variable as part of another variable name. Maybe you don't understand these rules, maybe you have to defend. But if you follow this, these rules will constrain you to construct your program correctly. The easy way is to let those low-level programmers stay at the low-level forever.
12. Learn how to measure program performance. You will be surprised to find that you can learn a lot of extra knowledge.
13. Learn to treat problem details and problem consequences differently. The details of the problem will not cause much difference, and the consequences of the problem can lead to the world's destruction. Only focus on the consequences.
14. Pay close attention to your users / customers / managers. Helping them recognize their "what" is more important than helping them understand their "how".
15. Write a framework, whether you plan to use it or not. You will learn what you cannot learn from other means.
16. Teach others what you know—by speaking or writing. Eventually this will become an opportunity to educate yourself.
17. Always say "Yes" to your customers / users, even if you are not sure. In 90% of cases, you will eventually find a way to achieve it. 10% chance, you will go to apologize to them. This is a small price paid for important personal growth.
18. Look for other people's codes that do amazing things but are confused. Refactor it. Then throw it away and vow that you will never make the same mistakes they made. (You will find many such programs.)
19. Data always> theory or opinion. Learn data by developing things.
20. If possible, start your own business (service or product). You will learn a lot about programming that you will never learn as an employee.
