Wind and rain 20 years: 20 programming experience accumulated by predecessors __ Programming

20 years of wind and rain: 20 programming experience accumulated by predecessors

Url:http://blog.sina.com.cn/s/blog_6ede15b10100njj2.html

Jonathan Danylko, author of Jonathan Danico, is a freelance web architect and programmer who has more than 20 years of programming experience in areas such as e-commerce, biotechnology, real estate, healthcare, insurance and utilities. As Jonathan said in the article, this paper is suitable for newly graduated college students and novice programmers. If you are an advanced developer, you may see yourself in this article.

I've been programming since I was 11 years old, and I've always liked technology and programming. Over the years, I have accumulated some difficult and easy experience. As a programmer, you may not have the experience, but I will dedicate them to those who want to learn more from them.

I will continue to update these experiences, I may have more feelings, but as far as I am looking this 20, I think there is basically no need to add additional items to the list below. The following is my most unforgettable experience so far.

　　 1. Estimate the time required to resolve the problem. Don't be afraid, admit it. I've seen programmers sitting in front of a monitor for 8 hours to solve a particular problem. Set a time limit for yourself, 1 hours, 30 minutes, or even 15 minutes. If you can't solve the problem during this time, ask for help or find an answer online instead of trying to be a "super stacker".

　　 2. A programming language is a language, just a language. As time goes on, as long as you understand the principles of a language, you will find similarities between the various languages. The language you choose, you should feel "comfortable" and be able to write valid (and concise) code. Most importantly, let the language adapt to the project, and vice versa.

　　 3. Do not focus too much on the "design pattern" of the program. Sometimes it's easier to write a simple algorithm than to introduce a pattern. In most cases, the program code should be simple and understandable, and even cleaners can read it.

　　 4. Back up your code frequently. When I was young, I had the experience of losing a lot of code because of a hard drive failure, and it was a terrible experience. As long as you do not have a backup, it should be like a strict deadline, the customer needs tomorrow. This is the source/version control software.

　　 5. Admit that you are not the best programmer-know-how. I often think that I know enough about programming, but there are always others who are better than you. The so-called, "a mountain is always higher than a mountain." So, come to them.

　　 6, study and study again. As the 5th says, I often take a computer or programming-related magazine or book in My Hand (don't believe, ask my friend). Admittedly, there are a lot of techniques you don't know, and you can learn from them to keep it up. If you have a smart way to get the new technology you need, you should keep learning every day.

　　 7. The EternalChange. You should treat technology/programming knowledge as you do with stocks: diversify. Don't feel good about yourself in a particular technology. If that technology or language is not enough, you might as well start updating your resume now and start a new training program. What are the main principles that I can keep moving forward? Learn at least two or three languages, so if a language is out of date, you can rely on another language to learn new technology.

　　 8. To recruit new people. Assist and develop beginner/entry-level developers to learn good programming methods and techniques. You may not know yet that you will be more confident when you help them advance to a higher level.

　　 9. Simplify the algorithm. Code like a demon, after you have finished coding, should turn around and optimize it. In the long run, improvements here and there will make it easier for later support staff.

　　 10. Write the document. Whether it's a Web service API or a simple class, you try to write the appropriate documentation. I used to be proud of code comments that were criticized for being overly annotated. Adding a line of comments to three lines of code takes only a few seconds. If that's a more difficult technique to understand, don't worry too much about annotations. If you can do your job well, most architects, backup programmers, and support groups will appreciate it.

　　 11. Test, test and test again. I am a black box test fan. When you have finished coding, you begin when you are "recognized". If your company has a QA department, if you have errors in your code, you will get more comments than the project manager. If you do not thoroughly test your own code, it is feared that you have developed more than just code, and may also be notorious.

　　 12. Celebrate every success. I've seen a lot of programmers shaking hands with peers, high fives, or even dancing when they solve a programming technical problem. Everyone encounters "Epiphany" in their lives. If a programmer is happy to call you to see his extraordinary code, maybe you've seen this code 100 times, but you should celebrate the 101th time for this guy. (Editor's note: "Nine ways to celebrate success".) ）

　　 13. Check the code frequently. In the company, your code needs to be checked regularly (including self-examination and other peer checks). Do not look at other people's inspection, as the code to the style of demanding. They should be seen as constructive criticism. For individuals, check your code frequently and ask, "How can I write better?" "This will allow you to accelerate your growth and make you a better programmer."

　　 14. Review your code. When you see your previous code, there are usually two ways: "hard to believe that this code was written by me"and" hard to believe, this code was written by me. " The first kind is often a tone of disgust and is thinking about how to improve it. You may marvel that the old code can be resurrected as a better program, even a complete product. The second usually carries a sense of surprise and fulfillment. Developers should be able to work on one or two of their own projects, allowing people to stand and watch the project. Also, based on your superior programming skills, you can take past programs or projects and update them to better products or ideas.

　　 15. Humor is indispensable. In my 20 years of development, I haven't met a programmer who doesn't have a sense of humour. In fact, in our line of work, humor is a must.

　　 16. Beware of omniscient programmers, programmers unwilling to share, and inexperienced programmers. When you meet these kinds of programmers, you should be humble. Omniscient programmers are more likely to be heroes than team members; Conservative programmers write their own code, while inexperienced programmers ask you every 10 minutes, and when the code is done, the code is yours, not theirs.

　　 17. Any project is not so simple. Friends, family and colleagues have asked me to rush to do something and rush to do a program or website. For such a thing, we should plan from both sides in order to make things that will satisfy both parties. If someone at first wanted a Web site with only 3 pages using Microsoft Access, it would probably turn into a 15-page Web site, with SQL Server, a forum, and a custom CMS (Content management System).

　 18. Don't take it for granted at any time. If you undertake a simple project, you may think that some part can be done easily. Don't think so. Unless you have a class, component, or piece of code that has already been written, and the existing project has been tested. Don't think it will be easy.

　　 19. No software has been completed. A programmer once told me that no software was done, it was just "done for the time being". This is wise advice. If the customer is still using the program you are writing, and has withstood the test of time. If there is a chance, you are still updating it, this is not a bad thing, it makes you continue to move forward.

　　 20. Patience is a virtue. When customers, friends, or family members use a computer, they may be frustrated and want to smash the computer or go out of their way angrily. I've been telling them, "You're the one who controls the computer, not the computer." "You have to be patient with a computer that's used for programming." Once the programmer knows the problem, they will stand on the computer's point of view and say, "Oh, that's why it's done." ”

　　 Editor Something

Have a deep feeling about this article. Although this article does not have flowery rhetoric, which simple truth, in fact, is not only applicable to the program, the same can be extended to other industries. Remember before practicing the word, always feel at that time write very well, but later looked back, also will think "this incredibly is I write the word." ”

In reading this article of friends, I do not know whether you have seen the figure of their own. You are welcome to share your feelings with you in your microblog or comments.