Top 20 programming lessons I 've learned in 20 years

I 've been programming since I was 11 and I 've loved technology and
Programming every since. There are some hard and easy lessons I 've learned over
Time. As a fellow programmer, you may not have experienced these, but I'm
Offering them to individuals who are interested in learning more from my
Experiences.

I'll be updating this as time goes on. I may have more, but in my 20 year
Period, I don't think there are any additional rules that this list doesn't
Include.

Here are my most memorable lessons so far.

1. Set a duration of how long you think it shoshould take to solve
   Problem-C 'mon, admit it! I'm just as guilty as the next programmer.
   I 've seen programmers sit in front of a monitor for eight hours at a time trying
   To solve a particle problem. Set a time table for yourself of 1 hour, 30
   Minutes, or even 15 minutes. If you can't figure out a solution to your problem
   Within your time frame, ask for help or research your problem on the Internet
   Instead of trying to be super-coder.
2. A language is a language-Over time, once
   You understand how one language works, you'll notice similarities between other
   Ages. The language you choose shoshould provide you with a suitable "comfort"
   Level, the ability to produce efficient (and clean) code, and, above all, allow
   The language to suit the project and vice-versa.
3. Don't over-"Design Pattern" applications-Sometimes it's
   Just easier to write a simple algorithm than it is to induplicate ate a singleton or
   Facade Pattern. For the most part, it even allows for cleaner, understandable
   Code.
4. Always backup your code-I 've experienced a complete hard
   Drive failue and lost a lot of code when I was younger and felt horrible because
   Of what had happened. The one time you don't back up your data may be the one
   Time where you have a strict deadline with a client and they need it tomorrow.
   Source code/version control applies here as well.
5. You are not the best at programming. Live with it.-I
   Always thought that I knew so much about programming, but there is always
   Someone out there better than you. Always. Learn from them.
6. Learn to learn more-With Number Five explained, I 've
   Always had a magazine or book in my hand about computers or programming (ask my
   Friends, they'll confirm). True, there is a lot of technology out there and
   Keeping up with it is a fulltime job, but if you have a smart way of processing ing
   Your news, you'll learn about new technology every single day.
7. Change is constant-Your knowledge of technology and/or
   Programming shoshould be similar to how you treat stocks: Diversify. Don't get too
   Comfortable With a participating technology. If there's not enough support for that
   Language or technology, you might as well start updating your resume now and
   Start your training period. My general rule of thumb that has kept me going?
   Know at least two or three ages, so if one dies off, you have another one
   To fall back on while you train for a new technology.
8. Support Junior-Assist and train the junior/entry-level
   Developers on good programming guidelines and techniques. You never know... you
   May move up in rank and you'll all feel more confident having personally trained and
   Prepared them for their next position.
9. Simplify the algorithm-Code like a fiend, but once you're
   Done, go back through your code and optimize it. A little code improvement here
   And there will make support happier in the long run.
10. Document your code-Whether its documenting a Web Service
    API or documenting a simple class, document as you go. I 've been accused
    Over-commenting my code and that's something I'm proud of. It only takes
    Second to add an additional comment line for each 3 lines of code. If it's
    Harder technique to grasp, don't be afraid to over-comment. This is one problem
    Most sort ts, backup coders, and support groups don't complain about if
    You 've done your job right.
11. Test, test, test-I'm a fan of black box testing.
    When your routine is finished, your "stamp of approval" period starts. If you
    Have a Quality Assurance Department, you may be talking more to them than your
    Project Manager regarding errors in your code. If you don't test your code
    Thoroughly, you may develop more than code. Possibly a bad reputation.
12. Celebrate every success-I 've met a lot of programmers who
    Have Conquered headache-style problems with a great programming technique and
    Celebrated with a fellow programmer by doing the "Shake", the high-five, or even
    A "happy dance." Everyone has enlightening periods in their life and even though
    That one happy coder asked you to come and see his extraordinary piece of code
    And you 've seen that one piece of code over 100 times in your experiences,
    Celebrate the success of a fellow developer for the 101-st time.
13. Have code reviews frequently-On projects and personally.
    In the company, you will always have code reviews of how well you coded
    Something. Don't look at it as people crucifying your coding style. Think of it
    As constructive criticism. On the personal front, review your code and always
    Ask, "How coshould I have done it better? "This will accelerate your learning and
    Make you a better programmer.
14. REminisce about your code-There are two
    Ways to looking at old Code: "I can't believe I wrote this code" and "I can't
    Believe I wrote this code. "The first statement is often of disgust and
    Wondering how you can improve it. You 'd be surprised at how old code can be
    Resurrected into a possible and better routine, or maybe even an entire product.
    The second statement is of amazement and achievement. Developers have their one
    Or two project code achievements that they completed and had everyone standing
    Up and taking notice. Again, based on your excellent coding ability, you cocould
    Take those past routines or projects and update them into a better product or
    Idea.
15. Humor is necessary-In my 20 years of development, I have
    Never met a programmer who hasn't had a decent sense of humor. Actually, in this
    Industry, it's a requirement.
16. Beware the know-it-all, possessive coder, And the inexperienced
    Coder-Humble yourself when you meet these types of coders.
    Know-It-All tries to upstage you instead of working as a team player,
    Defensive coder created code that he doesn't want to share with anyone, and
    Inexperienced coder constantly asks for maintenance ance every ten minutes where
    Finished code developed is yours, not theirs.
17. No project is ever simple-I 've been asked by friends,
    Family, and associates to just "whip something up for me." to "Whip" Up
    Program or Web site, it takes planning from both parties to complete something
    That both sides can appreciate. If someone needs a 3-page web site
    Microsoft Access from the start, it winds up becoming a 15-page web site
    SQL Server, a forum, and a custom CMS (Content Management System ).
18. Never take anything for granted-If you take on a simple
    Project, you may think that a certain section will be easy to complete. Don't
    Think that even for a moment. Unless you have a class, component, or piece
    CodeAlready coded... And has been tested thoroughly... and is in
    Production from an existing project, don't think it will be easy.
19. Software is never finished-A fellow programmer once told
    Me that software is never finished, it's "temporarily completed." sound advice.
    If the client is still using a program you wrote and has stood the test of time,
    Chances are, you are still updating it, which isn't a bad thing. It keeps you
    Working.
20. Patience is definitely a valid UE-When clients, friends, or
    Family members use a PC, they get frustrated and proceed to hit a component
    The PC or storm off. I keep telling everyone, "you are controlling the computer
    Not the other way around. "You need to have a certain level of patience
    Programming computers. As soon as programmers understand what they did wrong,
    They look at it from the computers point of view and say, "Oh, that's why it was
    Doing that ."

I hope this list of lessons learned have either own red or provided
Chuckle for some people.

 

I have been programming since I was 11 years old and have always liked technology and programming. Over the years, I have accumulated some difficult 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 from them.

I will continue to update these experiences, and I may have more thoughts, but over the past 20 years, I think there is no need to add anything to the list below. The following is my most memorable experience.

1.
Estimate the time required to solve the problem.Don't be afraid. Admit it! I have seen some programmers SIT 8 hours in front of the monitor to solve a special problem. Set a time limit for yourself: 1 hour, 30 minutes, or even 15 minutes. If you cannot solve the problem during this period, ask for help or find the answer online, instead of trying to be a "super coder ".

2. a programming language is just a language.As time passes, as long as you understand the principles of a language, you will find similarities between different languages
. The language you select should be "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 Model" of the program ".Sometimes it is easier to write a simple algorithm than to introduce a certain mode. In most cases, the program code should be easy to understand, and even the cleaners can understand it.

4.
Back up code frequently.When I was a young man, I lost a lot of code due to a hard drive failure, which was terrible. As long as you do not have a backup, you should have a strict deadline and the customer will need it tomorrow. At this point, the source code/version control software is ready to use.

5. Admit that you are not the top programmer-
Unknown.I often think that I know enough about programming, but there are always others who are better than you. As the saying goes, "a mountain is always higher than a mountain ". So, look at them!

6.
Learn again.As mentioned at, I often hold a computer or programming-related magazine or book in my hand (don't believe it, you can ask my friends ). It is true that there are always a lot of technologies you don't know, and you can learn from them to stay behind. If you have a smart way to get the new technology you need, you should keep learning every day.

7.
PermanentChange.You should treat technology/programming knowledge as you do with stocks: diversity. Do not feel good about yourself in a specific technology. If that technology or language does not have enough support, you might as well start updating your resume and start a new training program now. What are the main principles that I can keep going? There are at least two or three languages, so if a language is outdated, you can still rely on another language when learning new technologies.

8.
Bring New people together.Assists and develops beginner/beginner developers to learn excellent programming methods and skills. Maybe you still don't know. When you help them move toward a higher level, you are also upgrading to a higher level, and you will be more confident.

9. simplified algorithms.Code is like a devil. After you complete the encoding, you should go back and optimize it. In the long run, some improvements here or there will make it easier for later support staff.

10.
Compile the document.Whether it is a Web Service API or a simple class, you should try to write the relevant documents. I was once proud of the code comments, and some people accused me of excessive comments. Add a line of comment to the three lines of code. It takes only a few seconds. If it is a hard-to-understand technology, don't worry too much about comments. If you can do your job well, most architects, backup programmers, and support groups will appreciate you.

11.
Test, test, and then test.I am a fan of black box testing. After you complete the encoding, you will start to "be recognized. If your company has a QA department and your code has errors, you will get more comments than the project manager. If you do not thoroughly test your code, I am afraid you will not only develop the code, but may also be notorious.

12.
Celebrate every success.I have seen many programmers shake hands, clap hands or even dance with their peers after solving programming technical difficulties. Everyone will have an epiphany in life ". If a programmer is happy to come and ask you to see his extraordinary code, you may have read this code 100 times, but you should also celebrate 101st times for this guy.

13.
Check the code frequently.In the company, your code should be checked frequently (including self-check and other colleagues' check ). Do not look at others' checks as harsh on the Code style. They should be viewed as constructive criticism. Personally, I often check your code and ask myself, "How can I write better ?"
This will allow you to accelerate your growth and become a better programmer.

14.
Review your code.When you see your previous Code, there are usually two ways: "difficult to believe, this code is written by me" and "difficult to believe, this code is written by me ". The first is often a nasty tone and is thinking about how to improve it. You may be amazed that the 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 everyone can stand up and view the project. Similarly, based on your superior programming capabilities, you can take out past programs or projects and update them into better products or ideas.

15. Humor is indispensable.In my 20 years of development, I haven't met any programmer who has no sense of humor. In fact, humor is a must for us in this line.

16.
Beware of programmers who do not know, do not want to share, and have experienced programmers.When you meet these programmers, you must be humble. An unknown programmer wants to be a hero rather than a team member. Conservative programmers write their exclusive code. inexperienced programmers will ask you every 10 minutes, after the code is complete, the code is yours, not theirs.

17.
Any project is not that simple.My friends, family members, and colleagues once asked me to rush to do something and to make a program or website. For such a thing, we should make a plan from both parties to make something that will satisfy both parties. If someone needs to use Microsoft
Access websites with only three pages, but it is likely to become a website with 15 pages, and use SQL
Server, there is a forum, and a Customized CMS (Content Management System ).

18.
Do not take it for granted at any time.If you undertake a simple project, you may think that some part can be completed easily. Never think so! Unless you have a class, component, or a piece of code that has been written, and has passed the test in an existing project. Don't think it will be easy.

19.
No software has been completed.A programmer once told me that no software has been completed, but it is "completed temporarily ". This is wise advice. If the customer is still using the program you wrote and has stood the test of time. If you have the opportunity, you are still updating it. This is not a bad thing, and it keeps moving forward.

20.
Patience is a virtue.When a customer, friend, or family member uses a computer, they may be frustrated and want to drop the computer or leave. I keep telling them, "You have control over your computer, not your computer ." Be patient with the computer used for programming. Once programmers know the problem, they will view the problem from the computer's perspective and say, "Oh, that's why it does ."

This article from: http://www.jobbole.com/entry.php/322

From: http://www.dcs-media.com/Archive/20-20-top-20-programming-lessons-ive-learned-in-20-years-FH