20 Experience sharing of senior programmer programming

Jonathan Danylko, author of Jonathan Danico, is a freelance web architect and programmer with over 20 years of programming experience in the fields of e-commerce, biotechnology, real estate, healthcare, insurance and utilities.

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

Although I think I will continue to update these experiences, there may be more feelings, but in my 20, I think the following list basically does not need to add extra things. Here is the most memorable experience I have ever had:

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 the answer online instead of trying to be a "super stacker".

2. Programming language is a language, just a language. as time goes by, as long as you understand the principle of a language, you will find similarities between the various languages. The language you choose, you should feel "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 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 code should be easy to understand and even cleaner to read.

4. Always back up your code. when I was young, I had the experience of losing a lot of code because of a hard drive failure, and it was a horrible experience. As long as you do not have a backup at a time, it should be like a strict deadline, customers need tomorrow. This is the source/version control software.

5. Admit that you are not the top programmer-know-how. I often think that I know enough about programming, but there are always others who are better than you. It is so-called, "a mountain is always higher than a mountain." So, go with them!

6. Learn and learn. as the 5th says, I often get a computer or programming-related magazine or book in my hand (I can ask my friends if I don't believe it). Admittedly, there's always a lot of technology you don't know about, and you can learn from it to keep it from falling behind. If you have a smart way to get the new technology you need, you should keep learning every day.

7. Eternal change. you treat technical/programming knowledge as you would with stocks: diversification. Don't feel good about yourself on a particular technology. If that technology or language doesn't have enough support, 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 to three languages, so if a language is out of date, you can rely on another language when learning new technologies.

8. Recruit new people. Assist and develop beginner/starter developers to learn excellent programming methods and techniques. Perhaps you do not know, in helping them to move to a higher level, you are also in the higher level of ascension, you will be more confident.

9. Simplify the algorithm. code like a demon, after you've finished coding, you should turn back and optimize it. In the long run, some of the improvements here or there will make it easier for later support staff.

10. Writing a document. whether it's a Web service API or a simple class, you write the appropriate documentation as much as possible. I used to be proud of the code comments, because of excessive comments and someone accused. Add a line of comments to the three lines of code, which only takes a few seconds. If it's a technology that's more difficult to understand, don't worry too much about annotations. Most architects, backup programmers, support groups will appreciate you if you can do your job well.

11. Test, test and re-test. I am a black box test fan. When you have finished coding, you are "recognized" when you start. 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 don't test your code thoroughly, I'm afraid you're developing more than just code, and you might be notorious for it.

12. Celebrate every success. I've seen many programmers shake hands, clap, or even dance with their peers after solving programming challenges. Everyone in life will encounter "Epiphany". If a programmer is happy to ask you to look at his extraordinary code, you may have read this Code 100 times, but you should also 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 should be checked frequently (including self-examination and other colleague checks). Don't look at other people's checks as a demanding code style. They should be seen as constructive criticism. For individuals, check your code frequently and ask yourself, "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: "Hard to believe, this code I wrote" and "hard to believe, this code is written by me." The first is often a tone of disgust, and in thinking how to improve it. You may marvel that the old code can also be resurrected into a better program, even a complete product. The second is usually with a sense of surprise and accomplishment. Developers should have one or two of their own completed project results, can make people can't help standing up 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-year development career, I haven't met any programmer who has no sense of humor. In fact, in our line of work, humor is an essential item.

16. Beware of all-knowing programmers, programmers who don't want to share, and inexperienced programmers. When you meet these kinds of programmers, you have to be humble. An omniscient programmer who wants to be a hero rather than a team member; Conservative programmers write their own code, and inexperienced programmers ask you every 10 minutes, and when the code is done, the code is yours, not theirs.

17. Any project is not that simple. friends, family, and colleagues have asked me to do something hastily, rush to do a program or website. For such a thing, we should make a plan from both sides, in order to make things that both sides will be satisfied. If someone initially just needs a site with 3 pages using Microsoft access, it's likely to become a Web site with 15 pages, use SQL Server, have 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 a part can be easily completed. Don't think like that! Unless you have a class, component, or a piece of code already written, and the existing project has been tested and passed. Don't think it's going to be easy.

19. The software has never been finished. once a programmer told me that no software was done, it was just "done for the time being". This is a wise advice. If the customer is still using the program you wrote, and has withstood the test of time. If there is a chance, you are still updating it, this is not a bad thing, it keeps you moving forward.

20. Patience is a virtue. when customers, friends, or family members use a computer, they may be frustrated and want to hit the computer or leave angrily. I've been telling them, "You control the computer, not the computer that controls you." "You have to be patient with the computer that you use as a programmer. Once the programmer knows where the problem is, they will look at the computer and say, "Oh, that's why it's done." ”

Recommended Reading

7 basic practical algorithms that programmers need to know and how to explain them

7 features of an efficient programmer

Ten programming taboos that programmers must pay attention to

Analyze the programmer's several stages of growth

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

20 Experience sharing of senior programmer programming