20 programming experiences I've had in 20 years.

I've been programming since I was 11 years old and I've always loved technology and programming. These are the lessons I have been getting. As a programmer, you may need such advice. I want everyone to learn more when they get the advice.

I will be constantly updated here and I may have more to write about, but for my 20 look, I don't think there is much more to be added to this list. :-)

That's the lesson I've been most impressed with so far.

1. Estimate the time you need to solve the problem. C ' Mon,admit it! I've seen programmers sitting in front of a monitor for 8 hours in order to solve a particular problem, and I feel guilty like the next programmer. Set a timetable for yourself, every 1 hours, 30 minutes, or even 15 minutes. If you cannot find a solution to the problem during this period, seek help from others, or find the answer on the internet instead of trying to do super-coder.

2, programming language is a language, but also is only a language. As time grows, as long as you understand how a language works, you will find similarities between the various languages. The language you choose should make you feel comfortable and be able to write effective (and concise) code. It is always important to make the language itself suitable for this project, and vice versa.

3, do not overdo-write "design mode" of the program. Sometimes it's much easier to write a simple algorithm than to introduce a pattern. In most cases, you should write code that is easy to understand, even if the cleaners have to read it. :-)

4. Always back up your code. When I was young, I had a hard drive and lost a lot of code, which made me feel rather irritable. Once you do not back up your data, it is as if a customer has a strict deadline tomorrow will need their things. (The one time you don't back up your data is the one of the one time where you had a strict deadline with a client and they need It tomorrow. This is the source/version control program can help you.

5. Accept the fact that you are not the most bullish programmer. I often think that I have had enough knowledge of programming, but I often find that someone is obviously better than me. So, learn from them.

6, Learning and learning. As the fifth article says, I often get a computer or programming-related book and magazine (My friends can testify) in my hand. Really, you can learn a lot of technology, so that you can not lag behind in the work. Of course if you have a better way to get in touch with the new technology you need, then you should learn it every day.

7.change is always happening.。 Your familiarity with programming techniques is as if you are dealing with a stock: it is a change. Don't feel good about a particular technology. If you don't have enough support for this technology or language, you'd better start updating your resume right away and start taking training. The main principle of my separation is to see if this technology can keep me going. Learn at least two or three languages so that if one is not, you can also rely on another when learning new technologies.

8, give help to the novice. Assist and develop novice/beginner developers with good programming skills. You may never realize ... This way you can make a lot of people grow up, and you will feel happy when you develop them to prepare for the next position.

9, let the algorithm simplification. The code is like a friend, and after you've finished coding, you should look at it again and optimize it. The code here or there a little bit of improvement, will make later long-term maintenance of people much easier.

10. Add comments to the code. -whether it's commenting on a Web service's API or commenting on a simple class, you do just that. I've been blamed for excessive code comments, and that's what I'm most proud of. Adding a line of comments to three lines of code will only take you a few seconds. If it's a tricky technique, don't worry about excessive annotations. You do what you have to do, and this is where the architect, the coding assistant, and the support group are least likely to complain.

11, testing, testing, testing I am a black box test of the CU. When you're done coding, you're "certified" when you start. If you have a quality assurance department, they will comment more than the project manager's comments on your mistakes. If you don't test your code at all, I'm afraid you're developing more than just code, and maybe you have a bad reputation.

12, for each successful celebration. Many programmers I've met have been shaking hands, clapping and even dancing with their peers when it comes to solving a headache problem with a programming technique. Everyone in life will encounter the "enlightened" time. A programmer is happy to ask you to look at his original code, and you may have read the Code 100 times, but you should also celebrate this success for the 101th time for this guy.

13.always check your code.。 Whether it's a project or an individual, you should always check your code in the company, instead of blaming others for a blow, but seeing them as constructive criticism. For individuals, always check your code and ask yourself, "How can I make it better?" This will allow you to grow faster and make you a better programmer.

14.Review your past code。 When you see your old code, there are often two kinds of expressions: "Hard to believe, I actually wrote the code" and "hard to believe, I actually wrote a kind of code." The first expression is often a tone of disgust. Think about how to improve it, and you'll be pleasantly surprised when you let these super-old code revive and become a better, more normal program, or even a complete product. The second expression often carries a sense of surprise and accomplishment. Developers should complete one or two test-proof, stand-alone engineering code. In addition, you can use the code or the project to make them a better product or idea, it depends on your good code ability.

15.a sense of humor is a must。 In my 20-year development career, I've never met a programmer who doesn't have a decent sense of humor. To be exact, in our industry, this is a must.

16.Beware of those who know everything, those who do not want to share, and those who have less experience.
When you meet these kinds of programmers, you must first be humble.
Those who know the most want to be a hero rather than a team member, while conservative people are writing code that they don't want to share. And those inexperienced programmers will ask you every 10 minutes, and when he's done, that code is yours and not theirs.

17, no project is always simple. I was asked by my friends, family and colleagues to do something and hurry to write a program or website. You should plan to accomplish what both parties will be happy with.
At first he might just need a Web site with 3 pages using Microsoft Access, but then it could become a Web site with 15 pages and use SQL Server, a forum, a custom CMS (Content management System)

18. Don't take it for granted at any time . If you take on a simple project, you might think that some parts are easy to complete. Don't think so unless you have a class, component, or a piece of code that has already been written and tested.

19, no software is already completed. A programmer once told me that no software was done, and they were only temporarily finished. This is a wise advice. If the client is still using the program you have written, it has endured the test period. It's also possible that you're still updating it, and that's not a bad thing, it can keep you working. :-)

20, patience is a strength. When customers, friends, or family members use a computer, they may be frustrated and want to smash the computer to the point of breaking away. I told them, "You're controlling your computer, not your computer." "You need to be patient with your computer for programming. As long as programmers understand their problem, they look at it from a computer point of view and say, "Well, that's the way it is." "

I hope this stack of experience will inspire some people or make you smile.

This article link: http://www.blueidea.com/tech/program/2010/7628.asp

http://mr-bug.iteye.com/blog/676335

20 programming experiences I've had in 20 years (RPM)