I have been very fond of technology and programming. Java from the beginning to the present Python, these years of learning experience and work experience, but also a period with so much everyone Python tutorials , accumulated some difficult and easy experience. As a programmer, you may develop some experience, or maybe Python entry you soon, maybe you have not these Python learning experience, not seen my share of Python tutorials , but I will offer them to those who want to learn more friends.
I will continue to update these experiences, I may have more feelings, but in my ten years of it, I think the following list of basic do not need to add anything extra. Here is my most memorable experience so far.
1. The estimated time required to solve the problem. Do not be afraid to admit it! I have seen some programmers in order to solve a particular problem while sitting in front of the monitor 8 hours. Set a time limit for yourself bar, 1 hour, 30 minutes or even 15 minutes. If during this period you Bunengjiejue problem, then go to seek help, or to find answers online, instead of trying to do it "super stacking member."
2. The programming language is a language, just a language. As time goes on, as long as you understand the principles of a language, you'll find similarities between the various languages. The language of your choice, you should feel "comfortable" and able to write effective (and simple) code. The most important language to allow for adaptation projects, and vice versa.
3. Do not focus too much on "design mode" program. Sometimes, write a simple algorithm, than the introduction of a pattern easier. In most cases, the code should be simple to understand, and even cleaners can understand.
4. Regular backup codes. When I was young, I have been lost due to hard disk failure experienced a lot of code, which is very frightening experience. As long as you do not back up once, they should be like a strict time limit, the customer will need tomorrow. At this point in relation to the source / version control software to show their talents.
5. admit that he is not the top programmer - know enough. I often think that I have more than enough understanding of programming, but there are always other people better than you. As the saying goes, "better than a mountain high mountain." So, to emulate them now!
6, and learn again. As of 5:00 said, I often take a computer program or a magazine or a book related (do not believe, you can ask my friend) in his hand. Indeed, there is always a lot of you do not know the technique, you can learn to remain behind. If you have a smart way to get the new technology you need, then you should insist on learning every day.
7. eternal change. You deal with technical / programming knowledge, just like you should be treated like stocks: diversification. Do not feel good about a particular technology. If that technology or language do not have enough support, then you might as well start now to update your resume and start a new training program. I can keep ahead of the main principles of what is it? Learn at least two to three kinds of language, so if a language out of date, you can also rely on another language while learning new technologies.
8. guide and support newcomers. Assistance and training developers junior / entry-learning good programming methods and techniques. Maybe you do not know, help them advance to higher level, you also upgrade to a higher level, you will be more confident.
9. The simplified algorithm. The code devil, after you been encoded, it should go back and optimization. In the long run, some improvements here and there, will later support staff easier.
10. Write document. Whether API Web service, or a simple class, you try to prepare the corresponding documentation. I was proud of code Howe notes, due to excessive comments and accusations. Three lines of code to add a comment to that you only need a few seconds. If it is a relatively difficult to understand technology, do not worry too much comment. If you are able to do their work well, most architects, programmers back-up, support group will thank you.
11. Test, test and then test. I am a fan of black box testing. When you are finished coding, you "recognized" when he began. If your company has a QA department, if there is an error in your code, you get comments, it will be more than the project manager. If you do not thoroughly test your own code, then I am afraid you will not only develop the code, you may also notorious.
12. celebrate every success. I have seen many programmers in programming after solving technical problems, and will partner handshake, high-five, or even dancing. Everyone will encounter in life. "Epiphany." If a programmer is pleased to tell you came to see his extraordinary codes, maybe you've seen this code 100 times, but you should be for this guy to celebrate 101st.
13. Always check code. In the company, you should always check the code (including self-examination and other colleagues examined). Do not take someone else's check as a code demanding style. They should be seen as constructive criticism. For individuals, always check your code and ask ourselves, "How can I write better?" This will make you accelerate your growth, make you a better programmer.
14. Review your code. When I saw myself in the previous code, usually have two ways: "difficult to believe, this is the code I wrote," and "difficult to believe, this is the code I wrote." The first is often disgusted tone, and thinking about how to improve it. You might wonder, the resurrection of the old code can become a better program, or even a complete product. The second surprise and usually with a sense of accomplishment. Developers should be one or two results of the project yourself, and let the people can not help but stand and gaze project concept. Again, based on your excellent programming skills, you can put the past out of the program or project, to update them to more outstanding products or ideas.
15. Humor is essential. In my years of development career, I have met a lot of humor programmers, what plaid shirt, jacket, stiff labels have been attached to the programmers who can only say that each person is different personalities. In fact, dry our line, in addition to technology, humor is also a must-have.
16. Beware of those omniscient programmer, programmers do not want to share, as well as less experienced programmers. When you encounter these types of programmers, you have to be humble. Omniscient programmer, but want to be a hero rather than a team; conservative programmer is writing the code for their exclusive; rather inexperienced programmers will every ten minutes to ask you, when after the completion of the code, the code is already yours, not them.
17. Any project will not be so simple. Friends, family and colleagues have asked me to rush to do something, do a rush program or website. For such a thing, you should make plans from both sides, in order to make the two sides will make satisfactory thing. If someone started as a need to use Microsoft Access, and only has three pages of the site, but it is likely to become a 15 page website and using SQL Server, there is a forum, there is a custom CMS (content management system).
18. Do not ever take it for granted. If you undertake a simple project, you might think that a certain part can be easily done. Do not think so! Unless you have a class, component, or section of code has been written, and the existing project has been tested. Do not think it will be very easy.
19. No software has been completed. There was a programmer told me that no software is completed, it is only "temporary completed." This is wise counsel. If the customer still use the program you write, and has stood the test of time. If you have a chance, you still update it, this is not a bad thing, it allows you to continue to move forward.
20. Patience is a virtue. When clients, friends or family members use the computer, they may be frustrated, and then want to hit the computer, or stormed away. I keep telling them, "You control the computer, not the computer control you." For a computer as a programmer, and you need to have some patience. Once the programmers know the problem, they will stand in the perspective of a computer problem, and say, "Oh, that's why it was done."