I have gained 20 programming experiences over the past 20 years.

I have been programming since I was 11 years old and have always liked technology and programming. These are my lessons. As a programmer, you may need such advice. I also hope that everyone can learn more while receiving such advice.

I will update it continuously. I may write more, but for the past 20 years, I think there is nothing more to add to this list. :-)

This is some of my most impressive lessons so far.

1. estimate the time required to solve the problem. C 'mon, admit it! I have seen some programmers sitting in front of the monitor for eight hours to solve a special problem. I will feel as guilty as the next programmer will be. Set a timetable for yourself, every hour, 30 minutes, or even 15 minutes. If you cannot find a solution to the problem during this period, ask for help from others, or find answers on the internet, instead of trying to do super-coder.

2. a programming language is just a language. As long as you understand how a language works, you will find similarities between different languages. The language you choose should make you feel comfortable and be able to write effective (and concise) code. It is always important to make the language itself fit for this project, and vice versa.

3. Do not overhead-write the "Design Pattern" program. Sometimes, writing a simple algorithm is much easier than introducing a certain pattern. In most cases, you should write easy-to-understand code so that even the cleaners can understand it. :-)

4. Back up code frequently. When I was young, I had a hard disk crash and lost a lot of code, which made me quite annoyed. Once you do not back up your data, it is as if a customer has a strict deadline and needs something tomorrow. (The one time you don't back up your data may be the one time where you have a strict deadline with a client and they need it tomorrow .) at this time, the source code/version control program can help you.

5. Accept the fact that you are not the best programmer. I often think that I already know enough about programming, but I often find someone obviously better than me. So, learn from them.

6. Learn again. As mentioned in Article 5, I often hold a computer or programming-related book or magazine in my hand (my friends can testify ). Really, you can learn a lot of technology from it, so that you will not lag behind in your work. Of course, if you have a better way to access the new technology you need, you should learn it every day.

7. Changes often occur. Your familiarity with programming technology is like you treat a stock: It's changing. Do not feel good about a specific technology. If this technology or language does not have enough support, you 'd better update your resume and start training immediately. The main principle of my separation is to see if this technology can allow me to continue. You should know at least two or three languages, so that you can depend on another one when learning new technologies.

8. Help new users. Assists and develops new/Novice developers so that they have good programming skills. You may never realize that this way you will make a lot of people grow up and you will be very happy when training them to prepare for the next position.

9. Simplify the algorithm. Code is like a friend. After coding, you should read it again from the beginning and optimize it. The code here or there is a little improvement, which will make it easier for people who will maintain it for a long time.

10. Add comments to the code. -Whether it is commenting on a WEB Service API or a simple class, you can do it. I have been accused of excessive code comments, but this is my most proud task. It takes only a few seconds to add a line of comment for the three lines of code. Don't worry about excessive comments if it's a hard-to-understand technique. What you should do is that architects, coding assistants, and support groups will never complain about.

11. Testing, testing, and testing I am the owner of the black box testing. When you complete the encoding, you start to "authenticate. If you have a Quality Assurance Department, the Project Manager will comment more on your incorrect comments. If you do not test your code at all, I am afraid you have developed more than code, and may have a bad reputation.

12. Celebrate success. Many of the programmers I 've met often shake hands, clap hands, or even dance with their peers to solve a programming technology headache. Everyone will encounter "suddenly open" in their lives. A programmer is happy to ask you to see his original code. With your experience, you may have read this code 100 times, but we should also celebrate this success 101st times for this guy.

13. Check your code frequently. Whether it's a project or an individual, you should always check your code in the company. Do not take others' accusations as a blow, but think of them as constructive criticism. For individuals, you often check your code and ask yourself, "How can I make it better?" This will allow you to grow faster and become a better programmer.

14. review your previous code. When you see your previous code, you often have two types of expressions: "It's hard to believe that I actually wrote a sample code" and "it's hard to believe that I actually wrote a sample code ". The first expression is often in an disgusted tone. Think about how to improve it. You will be pleasantly surprised when you make these super-old code recover and become a better, normal, or even complete product. The second expression often carries a sense of surprise and achievement. Developers should complete one or two engineering codes that can withstand the test and discussion. In addition, you can use these codes or projects to make them a better product or idea. It depends on your excellent code capabilities.

15. A sense of humor is a must. In my 20 years of development, I have never met a programmer without a sense of humor. Specifically, this is necessary in our industry.

16. Be careful with people who do not know, who do not want to share, and those who have insufficient experience. When you meet these programmers, you must be humble first. Those who are at a loss want to be a hero rather than a team member. conservative people are writing code that they do not want to share. The inexperienced programmers will ask you every ten minutes. When he completes the development, the code is yours rather than theirs.

17. No project is always simple. I was asked by my friends, family members, and colleagues to do something in a hurry and write a program or website. We should plan to accomplish what both parties will be satisfied. At the beginning, he may only need a website with three pages using Microsoft Access, however, the website may become a website with 15 pages and use SQL Server, a forum, and a custom CMS (Content Management System)

18. Do not take it for granted at any time. If you take over a simple project, you may think that some parts are easy to complete. Never think so unless you have a class, component, or a piece of code that has been written and tested.

19. No software is complete. A programmer once told me that no software has been completed, but they have been completed for the time being. This is wise advice. If the customer is still using the program you wrote, he has endured the testing time. Another possibility is that you are still updating it. This is not a bad thing. It can keep you working. :-)

20. Patience is a kind of strength. When customers, friends, or family members use computers, they may be frustrated and want to drop the computer so that they can get away. I told them, "You are controlling the computer, not the computer ." You must be patient with the computer used for programming. As long as programmers understand their problems, they will look at the problems from the computer perspective and say, "Well, that's not the case ."

I hope this stack of experience can inspire some people or give you a smile.