20/20: Top 20 Programming Lessons I've Learned in 20 Years

June 22^nd, 2020

In this re-post from 2006, I learned many hard lessons and hope to pass these on to college students, entry-level programmers, or advanced developers who just want a chuckle.

(This is an updated re-post from 2006-Nov-16)

UPDATE: I've recently added 10 more lessons learned that I posted here.

Editor's Note: This was a popular post back in 2006 and I've added more to it to enhance the article and not take away from the genuine tone I originally put into it. As I looked back on this post, I'm surprised how the content is still relevant in even today's programming standards.

I've been programming since I was 11 and I've loved technology and programming ever since. There are some hard and easy lessons I've learned.

As a fellow programmer, you may not have experienced these, but I'm offering them to individuals interested in learning more from my programming experiences.

I'll be updating this as time goes on. I may have more (update: I did here), 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; Timebox your 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 "Captain 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. Mostly, it even allows for cleaner, understandable code. In addition, it's always best to get it functional and then refactor the code later. :-)
Always backup your code
I've experienced a complete hard drive failure 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.
You are not the best at programming. Live with it.
I always thought I knew so much about programming, but there is always someone out there better than you. Always. Learn from them.
Yearn for the Learn Burn
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 full-time job, but if you have a streamlined medium of how to receive your news, you'll learn 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 update 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 or technologies 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, techniques, and patterns. 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, review your code, refactor, and optimize it. A minor code improvement here and there will make support happier in the long run.
Document your code
Whether it's 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 a 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 you finish coding, your "stamp of approval" period starts. If you have a Quality Assurance department, you may strike up more conversations with 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 a company, you will always have code reviews of how well you wrote 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 accelerates your learning and turns you into a better programmer.
Reminisce about your code
There are two ways to look 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 where 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 takes extreme pride in and doesn't want to share with anyone, and the inexperienced coder constantly asks for help 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) with an administration backend.
Never take anything for granted
If you take on a simple project, you may think a certain section will be easy to complete. Don't think like that for even 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 associate 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 just gives you more job security and keeps you working. :-)
Patience is definitely a virtue
When clients, friends, or family members use a PC, they get frustrated and hit the top of the PC or desk 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.