20 years of experience in programming

Author Jonathan danylko is a freelance web architect and programmer with over 20 years of programming experience, involved fields include e-commerce, biotechnology, real estate, medical care, insurance, and public utilities. As Jonathan said in his article, this article is suitable for graduates and beginners. If you are already a senior developer, you may be able to see yourself in this article. I have been programming since I was 11 years old and have always liked technology and programming. Over the years, I have accumulated some difficult and easy experiences. As a programmer, you may not have these experiences yet, but I will dedicate them to those who want to learn more from them. I will continue to update these experiences, and I may have more thoughts, but over the past 20 years, I think there is no need to add anything to the list below. The following is my most memorable experience. 1. estimate the time required to solve the problem. Don't be afraid. Admit it! I have seen some programmers SIT 8 hours in front of the monitor to solve a special problem. Set a time limit for yourself: 1 hour, 30 minutes, or even 15 minutes. If you cannot solve the problem during this period, ask for help or find the answer online, instead of trying to be a "super coder ". 2. a programming language is just a language. As time passes, as long as you understand the principles of a language, you will find similarities between different languages. The language you select should be "comfortable" and be able to write effective (and concise) code. Most importantly, let the language adapt to the project, and vice versa. 3. Do not pay too much attention to the "Design Model" of the program ". Sometimes it is easier to write a simple algorithm than to introduce a certain mode. In most cases, the program code should be easy to understand, and even the cleaners can understand it. 4. Back up code frequently. When I was a young man, I lost a lot of code due to a hard drive failure, which was terrible. As long as you do not have a backup, you should have a strict deadline and the customer will need it tomorrow. At this point, the source code/version control software is ready to use. 5. Admit that you are not the top programmer-lack of knowledge. I often think that I know enough about programming, but there are always others who are better than you. As the saying goes, "a mountain is always higher than a mountain ". So, look at them! 6. Learn again. As mentioned at, I often hold a computer or programming-related magazine or book in my hand (don't believe it, you can ask my friends ). It is true that there are always a lot of technologies you don't know, and you can learn from them to stay behind. If you have a smart way to get the new technology you need, you should keep learning every day. 7. Eternal changes. You should treat technology/programming knowledge as you do with stocks: diversity. Do not feel good about yourself in a specific technology. If that technology or language does not have enough support, you might as well start updating your resume and start a new training program now. What are the main principles that I can keep going? There are at least two or three languages, so if a language is outdated, you can still rely on another language when learning new technologies. 8. Bring New people together. Assists and develops beginner/beginner developers to learn excellent programming methods and skills. Maybe you still don't know. When you help them move toward a higher level, you are also upgrading to a higher level, and you will be more confident. 9. simplified algorithms. Code is like a devil. After you complete the encoding, you should go back and optimize it. In the long run, some improvements here or there will make it easier for later support staff. 10. Compile the document. Whether it is a Web Service API or a simple class, you should try to write the relevant documents. I was once proud of the code comments, and some people accused me of excessive comments. Add a line of comment to the three lines of code. It takes only a few seconds. If it is a hard-to-understand technology, don't worry too much about comments. If you can do your job well, most architects, backup programmers, and support groups will appreciate you. 11. Test, test and retest. I am a fan of black box testing. After you complete the encoding, you will start to "be recognized. If your company has a QA department and your code has errors, you will get more comments than the project manager. If you do not thoroughly test your code, I am afraid you will not only develop the code, but may also be notorious. 12. Celebrate every success. I have seen many programmers shake hands, clap hands or even dance with their peers after solving programming technical difficulties. Everyone will have an epiphany in life ". If a programmer is happy to come and ask you to see his extraordinary code, you may have read this code 100 times, but you should also celebrate 101st times for this guy. 13. Check the code frequently. In the company, your code should be checked frequently (including self-check and other colleagues' check ). Do not look at others' checks as harsh on the Code style. They should be viewed as constructive criticism. Personally, I often check your code and ask myself, "How can I write better ?" This will accelerate your growth and make you a better programmer. 14. review your code. When you see your previous Code, there are usually two ways: "difficult to believe, this code is written by me" and "difficult to believe, this code is written by me ". The first is often a nasty tone and is thinking about how to improve it. You may be amazed that the old code can also be revived into a better program, or even a complete product. The second is usually with a sense of surprise and achievement. Developers should have one or two projects completed by themselves, so that everyone can stand up and view the project. Similarly, based on your superior programming capabilities, you can take out past programs or projects and update them into better products or ideas. 15. Humor is indispensable. In my 20 years of development, I haven't met any programmer who has no sense of humor. In fact, humor is a must for us in this line. 16. Beware of uninformed programmers who do not want to share, and experienced programmers. When you meet these programmers, you must be humble. An unknown programmer wants to be a hero rather than a team member. Conservative programmers write their exclusive code. inexperienced programmers will ask you every 10 minutes, after the code is complete, the code is yours, not theirs. 17. Any project is not that simple. My friends, family members, and colleagues once asked me to rush to do something and to make a program or website. For such a thing, we should make a plan from both sides to make something that will satisfy both sides. If someone needs a website with only three pages using Microsoft Access at first, it is likely to become a website with 15 pages and use SQL Server, there is a forum and a Customized CMS (Content Management System ). 18. Do not take it for granted at any time. If you undertake a simple project, you may think that some part can be completed easily. Never think so! Unless you have a class, component, or a piece of code that has been written, and has passed the test in an existing project. Don't think it will be easy. 19. No software has been completed. A programmer once told me that no software has been completed, but it is "completed temporarily ". This is wise advice. If the customer is still using the program you wrote and has stood the test of time. If you have the opportunity, you are still updating it. This is not a bad thing, and it keeps moving forward. 20. Patience is a virtue. When a customer, friend, or family member uses a computer, they may be frustrated and want to drop the computer or leave. I keep telling them, "You have control over your computer, not your computer ." Be patient with the computer used for programming. Once programmers know the problem, they will view the problem from the computer's perspective and say, "Oh, that's why it does ." The editor's post is deeply touched by this article! Although there is no rhetoric in this article, the simple principle is not only applicable to programmers, but can also be extended to other industries. I remember that I always thought that I was writing well when I was practicing the word, but later I looked back and thought, "This is what I wrote !" Source: bole online source: http://www.dcs-media.com/Archive/20-20-top-20-programming-lessons-ive-learned-in-20-years-FH