editor: the original author Jonathan Danny (Jonathan Danylko) is a freelance web architect and programmer, with more than 20 years of programming experience, involving e-commerce, biotechnology, real estate, medical, insurance and public utilities in the field. As Jonathan said in his article, this article is suitable for freshmen and beginners. If you are a senior developer, you may be able to see yourself in this article.
when I was 11 years old, I've been programming, and I've always liked technology and programming. Over the years, I have accumulated some tough 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.
I will continue to update these experiences, and I may have more feelings, but for the last 20 years, I think the following list does not need to add extra. The following is my most memorable experience.
[b]1. estimates the time needed to solve the problem. [/b] don't be afraid, admit it! I have seen some programmers sitting in front of monitors 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 period, ask for help or find the answer online instead of trying to be a "super stack worker".
[b]2. programming language is a language, just a language. [/b] as time goes on, as long as you understand the principles of a language, you will find similarities between languages. You should feel comfortable in the language you choose, and you can write effective (and concise) code. Most importantly, let the language adapt to the project, and vice versa.
[b]3. should not pay too much attention to the "design pattern" of the program. [/b] sometimes, it is easier to write a simple algorithm than to introduce a pattern. In most cases, the program code should be simple and easy to understand, and even the cleaner can read it.
[b]4. often backups code. [/b] when I was young, I had lost a lot of code due to hard disk failures, and this experience was horrible. As long as you do not have a backup at the same time, it should be like a strict deadline. Customers will need it tomorrow. At that time, the source / version control software was displayed.
[b]5. admits that he is not the top programmer. [/b] I often think that I know enough about programming, but there are always others who are better than you. It is called "a mountain is higher than a mountain." So, look at them!
[b]6, learning and relearning. [/b] as I mentioned in the fifth point, I often take a computer or programming related magazine or book in my hand. Admittedly, there are always a lot of technologies you don't know. You can learn from them so as not to lag behind. If you have a clever way to get the new technology you need, you should study every day.
[b]7. perpetual [/b][b] change [/b][b]. [/b] your knowledge of Technology / programming should be diversified as you treat stocks. Don't feel good about yourself on a particular technology. If that technology or language has not enough support, you might as well start updating your resume now and start the new training plan. What is the main principle that I can keep going? At least two to three languages, so if a language is out of date, you can rely on another language when you learn new technology.
[b]8. brings new people. [/b] helps and nurture junior / beginner developers to learn excellent programming methods and techniques. Perhaps you do not know that when helping them move forward to a higher level, you are also upgrading to a higher level, and you will be more confident.
[b]9. simplification algorithm. [/b] code, like devil, should be looked back and optimized after you have finished coding. In the long run, some improvements here or there will make it easier for future support staff.
[b]10. writes documents. [/b], whether it is Web service API or a simple class, you try to write corresponding documents. I was proud of the code annotation, which was criticized for overcomment. It only takes you a few seconds to add three lines of code to one line of annotation. If that's a more difficult technology, don't worry about too much annotation. If you can do your job well, most architects, backup programmers and support groups will be grateful to you.
[b]11. test, test and retest. [/b] I'm a black box test fan. When you finish coding, you start when you are "recognized". If your company has a QA department, if you have errors in your code, you will get more comments than project managers. If you do not thoroughly test your code, then you will not only develop code, but you may also be notorious.
[b]12. celebrates every success. [/b] I've seen many programmers shake hands, clap or even dance with their partners after solving difficult programming problems. Everyone has a "Epiphany" in his life. If a programmer is happy to run for you to see his extraordinary code, you may have seen this code 100 times, but you should also celebrate this guy for 101st times. Editor's note: "[url=http://www.jobbole.com/entry.php/323:19v4plr2][color=#5c9911] celebrates the nine way of success, [/color][/url:19v4plr2]."
[b]13. often checks the code. [/b] in the company, your code should be checked regularly (including self checking and other colleagues' checking). Do not consider others' checks as demanding for code style. They should be regarded as constructive criticism. For individuals, check your code frequently and ask yourself, "how can I write better?" This will speed up your growth and make you a better programmer.
[b]14. reviews your code. When [/b] sees its previous code, there are usually two ways: "it's hard to believe, the code is what I wrote" and "it's hard to letter, the code is I wrote." The first is often the tone of disgust, and is thinking about how to improve it. You may be amazed that 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 people can not help but stand up and focus on projects. Similarly, based on your superior programming skills, you can take out past programs or projects and update them into more excellent products or ideas.
[b]15. humour is indispensable. [/b] in my 20 years of development career, I haven't met any programmer who has no sense of humor. In fact, humor is a must in our business.
[b]16. beware of omniscient programmers, programmers who do not want to share, and inexperienced programmers. [/b] when you meet these kinds of programmers, you must be modest. The omniscient programmer wants to be a hero rather than a team member; the conservative programmer is writing their exclusive code; the less experienced programmer will ask you every ten minutes, and when the code is finished, the code is yours, not his.
[b]17. no project will be that simple. [/b] friends, family members and colleagues asked me to rush to do something, rush to make a program or website. For such a matter, plans should be made from both sides to make things that satisfy the two parties. If someone just needed a web site with only 3 pages to use Microsoft Access at first, it would probably become a web site with 15 pages, with a SQL Server, a forum, and a custom CMS (content management system).
[b] 18. don't take it for granted at any time. [/b] if you undertake a simple project, you may think that a part can be easily completed. Don't think so! Unless you have a class, component, or code that has been written, and have been tested in existing projects. Don't think it's going to be easy.
[b]19. has no completed software. [/b] once a programmer told me that no software has been completed, it is only "temporarily completed." This is a wise advice. If the customer is still using the program you wrote, and has stood the test of time. If you have the chance, you are still updating it. This is not a bad thing. It keeps you moving forward.
[b]20. is a virtue. [/b] when customers, friends or family members use computers, they may be frustrated, and then want to smash the computer, or rush away. I've been telling them, "you control computers, not computers." You have to be patient with computers for programming. Once a programmer knows the problem, they will look at it from a computer's perspective and say, "Oh, that's why it does it."
[b] editor's words [/b]
is deeply touched on this article. Although this article does not have flowery rhetoric, its simple truth is not only applicable to programmers, but also can be extended to other industries. I remember when I used to practice calligraphy, I always felt good at that time, but later I looked back and thought, "this is what I wrote!"
friends who read this article, do you see yourself? You are welcome to share feelings with everyone in micro-blog or comments.