[cite]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.

Set a duration of how long you think it should take to solve a
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 particular 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.

A language is a language is a language - Over time, once
you understand how one language works, you'll notice similarities between other
languages. The language you choose should 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.

Don't over-"design pattern" applications - Sometimes it's
just easier to write a simple algorithm than it is to incorporate a singleton or
facade pattern. For the most part, it even allows for cleaner, understandable
code. :-)

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.

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.

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 receiving
your news, you'll learn about new technology every single day.

Change is constant - Your knowledge of technology and/or
programming should be similar to how you treat stocks: Diversify. Don't get too
comfortable with a particular 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 languages, so if one dies off, you have another one
to fall back on while you train for a new technology.

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 feel more confident having personally trained and
prepared them for their next position.

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.

Document your code - Whether its documenting a Web Service
API or documenting a simple class, document as you go. I've been accused of
over-commenting my code and that's something I'm proud of. It only takes a
second to add an additional comment line for each 3 lines of code. If it's a
harder technique to grasp, don't be afraid to over-comment. This is one problem
most architects, backup coders, and support groups don't complain about if
you've done your job right.

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.

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.

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 could I have done it better?" This will accelerate your learning and
make you a better programmer.

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 could
take those past routines or projects and update them into a better product or
idea.

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.

Beware the know-it-all, possessive coder, and the inexperienced
coder - Humble yourself when you meet these types of coders. The
know-it-all tries to upstage you instead of working as a team player, the
defensive coder created code that he doesn't want to share with anyone, and the
inexperienced coder constantly asks for assistance every ten minutes where the
finished code developed is yours, not theirs.

No project is ever simple - I've been asked by friends,
family, and associates to just "whip something up for me." To "whip" up a
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 with
Microsoft Access from the start, it winds up becoming a 15-page web site with
SQL Server, a forum, and a custom CMS (Content Management System).

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 of
code already coded...and has been tested thoroughly...and is in
production from an existing project, don't think it will be easy.

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. :-)

Patience is definitely a virtue - When clients, friends, or
family members use a PC, they get frustrated and proceed to hit a component of
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 for
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 inspired or provided a
chuckle for some people.