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

This post could be viewed as hard lessons learned for newly graduated college students, entry-level programmers, or advanced developers who just want a chuckle.

November 16th, 2006 at 5:30am — Comments: (84) — By: Jonathan Danylko — Tags: Business Lessons

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 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.
  2. 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.
  3. 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. :-)
  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 receiving your news, you'll learn about new technology every single day.
  7. 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.
  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 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 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.
  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 could 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 could 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. 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.
  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 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).
  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 of code already 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 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.

Picture of Jonathan Danylko
  • Jonathan Danylko Twitter Account LinkedIn Account Facebook Account

Jonathan Danylko is a freelance web architect and avid programmer who has been programming for over 20 years. He has developed various systems in numerous industries including e-commerce, biotechnology, real estate, health, insurance, and utility companies.

When asked what he likes doing in his spare time, he answers..."programming."

Related Posts


  1. whalehead
    November 16th, 2006 at 10:21am
    Remember, programming is like sex... one mistake and you support it forever!
  2. November 16th, 2006 at 10:24am
    Posting has been restored.

    Thanks for your patience.

    The Management.
  3. Carmaine
    November 16th, 2006 at 10:34am
    Thanks, whalehead :-)
  4. C0FAB39E-ED35-4024-9D9B-9E2D651FB01E
    November 16th, 2006 at 11:27am
    This is one of the best articles I've ever read on the realities of software development.

    I too have been programming for over 20 years and I can't mention these points enough to my staff.

    Can I add a few things?

    There are no silver bullets.  There are no universal solutions.  Yes, given enough time and money you can indeed make anything work, however: do not force square pegs (your pet solutions) into round holes (the problem at hand).  Keep your mind open and flexible and curious enough to find the correct solution.  The technically correct solution is not always the correct solution.

    Thanks for the great read.
  5. November 16th, 2006 at 12:29pm
    Thanks for the additional lesson and the kudos, architect.zero.

  6. excelsior
    November 18th, 2006 at 1:48am
    quite sums up my own experience as a developer, but it seems you havent found out about pragmatic programmers ...
  7. Daryl
    November 29th, 2006 at 1:44am
    Really Great !!

    This article helps me lot in web development field.
  8. November 29th, 2006 at 9:32pm
    Although i am only 15, and i have programmed for about 2 or 3 years now, alot of this i have already experienced (not quite so much the working part). Especially the "whip up this" or that or whatever. My science teacher asked me for a "quick database program". It turned out to be this massive database content live update system where people could schedule online and employees and admins logged in and customers set up payment and membership options.
  9. November 30th, 2006 at 4:16am

    The iceberg theory is how I tell people what a program/web site consists of: above the water is this little tip of the iceberg which is what everyone sees, but below the surface is what goes into making the application/web site.

    That's awesome! Thanks for the comment. :-)
  10. January 29th, 2007 at 11:53am
    I'd add this: Don't make it more complicated than it needs to be.  For example, to comment on this blog, one needs javascript to be running in the browser.  Was that really needed?  (I happen to have javascript turned off by default.  There's a Firefox plug in.  But I used to see sites that only worked with IE.  It wasn't required.)  This is more, 'simplify your requirements'.

    Also.  Listen to the teddy bear.  The story goes that at a big shop (it might have been at IBM), there was a table in the corner with a big teddy bear on it.  When you couldn't figure out what was wrong with your code, you could go explain it to the teddy bear.  It really works.  But, the story goes, management didn't understand this, and took it away.

    And. In the argument over if computer programming is engineering, consider that it isn't.  If you build a car, there are reused parts - screws, wheels, etc.  In a program, any resused parts are put into a subroutine.  So, almost nothing is reused.  While engineering is difficult, computer programs take that to an exponential absurdity.  Computer programming is engineering on steroids.  Rocket scientists should have it so easy.

    2. While a language is a language from the point of view of learning a new one, they aren't from the point of view of the application. A Turing machine can, in principal, be used to create a database backed web site - but that doesn't make it a practical tool for the job.

    5. While there are other programmers or even lifeless books that are smarter than you, and you can learn from them, sometimes the best way to learn something is to do it yourself.

    You can also learn something you already know better by teaching it to someone else.  You can use this to learn something better - by pretending to teach it to yourself the first time.

    7. Change is inevitable.  Except from vending machines.

    But you should also consider the evolution of computer languages.  In Evolution, the new species isn't better, it's just different.  The environment decides if it will live or go extinct.  Consider the C family tree.  Was C better than BCPL?  Well, structures are handy.  I mean, it's a real pain to create linked lists without them.  People did that in BCPL, though.  Was C++ better than C?  Operator overloading may be handy, but it can also be misused to obfuscate the code.  And, calling methods can be much higher overhead than C ever had.  It isn't always worth it.  And Java doesn't generally compile to the bare metal.  Each variant has trade offs.  So companies that say that they'll only use Java have chosen to hammer in nails with a lovely screwdriver.  And not a loose screw in sight.

    13. When you do a code review, review the code, not the coder.  But it's up to the coder to not take it personally.

    15. I don't use smileys to indicate humor ;-)  Feel free to laugh at the jokes - or not.  When the tree falls - or stands, in the woods, I don't hear it.

    19: All code needs to be rewritten.  But that doesn't mean it should be.

    20: Take your time. I type at around 70 words  a minute.  I hand-write at about 7. But if i hand write out code, then type it in, more total time has been spent, and fewer bugs result.  This takes less time than the resulting debugging.  And yet, I can kick out another 800 lines a day this way.  That's hardly slow.

    Just as mathematics can not be closed, there are no absolute truths (not even this one).  None of these rules are absolute.  You need to weigh them.  So, while the authority says "Go-to's are harmful", or even "BASIC causes brain damage", it can be demonstrated with clear examples that a go-to is the right tool for the job, and that BASIC was the right introductory language for many. Think about it.  There is no excuse for prejudice. The word 'prejudice' means 'without thinking', and you can't afford that.  So, while no program is bug free, I've written two that were bug free from the start.


    Every program has at least one bug.

    Every program can be reduced in size by at least on line.

    Therefore, every program can be reduced to a single line - which is a bug.


    Nothing is better than complete happiness.

    A buggy program is better than nothing.

    Therefore, a buggy program is better than complete happiness.
  11. Cem Kalyoncu
    May 28th, 2009 at 11:42pm
    Experience and wisdom can be read from your words and also Stephen's. Most of the advices around the Internet are either by the book advices that never fits into reality or written by a guy having few years experience that accomplished nothing but thinking himself as the best programmer around. The practices stated in here are invaluable to any programmer.
  12. January 12th, 2010 at 3:57am
    I can't remember the last time I read and article and was so amazed. It's just awesome how perfect these short lessons describe such a complex and different sector of technology.

    I linked this in my blog, please give me hint if that's not appreciated...
  13. dadum01
    January 12th, 2010 at 6:10pm
    Most the thing are true because it has happed to me. You cant state the obviouse. "they look at it from the computers point of view and say, "Oh, that's why it was doing that." " is soo true when programming.
  14. January 12th, 2010 at 6:14pm
    This list should be used as base for Code of Programmer.
  15. January 13th, 2010 at 4:39am
    thanks so much mr ......

  16. January 13th, 2010 at 9:36am
    I really liked reading this post. I can approve all the points.
  17. January 13th, 2010 at 9:57am
    I agree with the third point. It's not always very clever to write the perfect code in one line. It takes you ages figuring out what that beautiful cryptic line does.
  18. Fridrik
    January 13th, 2010 at 10:09am
    Excellent article!

    I would add one thing:

    Code for the end user. It doesn´t matter how fancy your code is or the architecture, if the end user can't do something just because the architecture of the application does not allow it, it really isn't good programming.
  19. January 13th, 2010 at 12:28pm
    Excellent post.
    I would add at the top:
    1. Keep learning every day.
    2. Less is (much) more.
    3. Go have fun and do something else form time to time. It will make you better coder/person.
  20. January 13th, 2010 at 12:36pm
    A friend of mine once said:

    Software is never finished, it is abandoned. ~ Corey Sanders

    I really like this until I came up with my corollary:

    Developers are never finished, THEY are abandoned.
  21. January 13th, 2010 at 1:17pm
    This is a great read! Thank you for sharing. Now I don't have to go through 20 years to learn these things.

    Although I have already learned a number of them, especially the bit about being ware of different types of programmers...
  22. January 13th, 2010 at 1:32pm
    LOVE THIS LIST! I am still a new developer and I love this list. Thanks for sharing your experience. : )
  23. January 13th, 2010 at 3:17pm
    Good points! I agree with you.
  24. January 13th, 2010 at 3:59pm
    About #20: I would rephrase it to: embrace the frustration. Computers can be frustrating, very much so, especially if you do complex stuff with them, like programming. If you know you will be frustrated eventually you can mentally prepare yourself for it and don't let it bother you that much. Sometimes the best solution for an annoying probem is time, spend more time with the problem.
  25. Curtis
    January 14th, 2010 at 7:54am
    16. You forgot the inexperienced-know-it-all, the guy who has no clue what he's doing, yet gives out advice as if he does. I work with one of those hehehe.
  26. January 14th, 2010 at 9:50am

    I'd rephrase or extend your comment slightly.

    *Design* for the *User*. *Write code* for the *next developer*.

    You aren't writing code for yourself, or fo r the user, or even for the compiler. You are writing code for the net programmer to debug or extend or optimise, so structure your code and leave comments, tests and documentation accordingly.
  27. January 14th, 2010 at 9:56am
    This is hinted at in tips 1 and 3, but if I was to give just one tip to future developers, it is this: *KISS* - Keep It Simple, Stupid!

    Keep the design as simple as you can, keep the code structure as simple as you can, keep your testing strategy as simple as you can, keep the documentation as simple as you can, keep the user interface as simple as you can, but in each case, never any simpler! You will never regret it.
  28. January 15th, 2010 at 4:35am
    Great list.... I totally agree with you.
  29. maxjgon
    January 15th, 2010 at 11:22am
    Thanks for sharing!!!
  30. January 15th, 2010 at 6:14pm
    Intresting post. Thanks
  31. Maggi
    January 20th, 2010 at 8:42am
    Very Interesting & Wonderful Post.....

    Thanks 4 Sharing!!!!!!!
  32. January 20th, 2010 at 11:00pm
    great post, good wisdom, thanks for passing it on.
  33. January 26th, 2010 at 1:36am
    Great post. I'm only 2 years in this industry, so that is absolutely cool to absorb knowledge of people who are 10 times longer there.
  34. Etirps
    February 12th, 2010 at 1:16pm
    Excellent post! For somewhat exhaustive list of don'ts check wikipedia anti-pattern.


  35. February 24th, 2010 at 12:02am
    Good points! I agree with you.
  36. vladimir
    March 3rd, 2010 at 5:50am
    I had a blast reading this post , I have about 19 years of Application Development and had total of 9 jobs.
    For me Every job was like a new book, some books you always read to the end ( i.e company went out of business ) , but some you throw in the trash can :-) , I also agree with the statement that programming is not Engineering - it's a state of mind...
  37. April 1st, 2010 at 8:46pm
    really nice and funny
  38. April 2nd, 2010 at 5:06am
    Great list. I have been programming for about 7 years now and I have personally experienced almost all of the things on this list.

    Just want to add one thing to rule 1, sometimes, if you've been sitting at a computer for more than 30 minutes without coming up with a solution, try working on a different problem. It usually gives you a fresh mind when you come back to your original problem. As Sherlock Holmes said: 'The best rest is a change of work'.
  39. August 18th, 2010 at 11:29pm
    Lesson number 15 is very important. Positive attitude is half the battle. Humor is the best remedy for many problems.
  40. carlos
    October 5th, 2010 at 12:15pm
    the points you mentioned does apply in the real world. i agree with you.
  41. October 10th, 2010 at 8:21pm
    Feels like reading a history of programming language development here. You got strong background there. Well done!
  42. October 11th, 2010 at 9:12pm
    Great article...

    A few things there i must admit i should do!!

    One that comes to mind is test test test!

    I have done a couple of silly things in web design because of not testing!

  43. October 12th, 2010 at 9:16am
    You are dead on. I wish I would have read these prior to going down the many wrong paths I have taken.

    Software is never finished! It's like a builder building his own home when they say "a builder's home is his last." As a a programmer, this is true. My own website is never done, always a work in progress.
  44. October 12th, 2010 at 10:05am
    You points hit the nail on the head, especially setting a scertain amount of time to solve a problem.

    We have all sat there and over run on the time we have allowed and this has messed the timing for the day up.
  45. November 10th, 2010 at 9:25pm
    I wish you where there when i was choosing my college course. Amazing advice thanks Johnathan Iam starting the open university in January thanks for the advice.
  46. November 12th, 2010 at 10:34am
    Yeah, I used to reminisce about code all the time, but looking back I can really connect the dots on how it made me a better hacker. If you start off using frameworks, youll miss out on a lot of the subtleties.
  47. November 12th, 2010 at 11:06am
    Great list, really. I love to read post from experienced guy like you.
  48. November 12th, 2010 at 11:14am
    Nice stuff to know ... congrats
  49. November 12th, 2010 at 11:16am
    10x for the info helped out very much
  50. November 12th, 2010 at 2:20pm
    Great job Jonathan. I just saw your website at reddit.

    This one is hard to be understand by a beginner.

    Just take a look on how a newbie ask question at this website:

  51. November 12th, 2010 at 4:10pm
    nice advice it is worth printing out
  52. Andrew de Andrade
    November 12th, 2010 at 8:47pm
    Checkout the Apprenticeship Patterns book. It's relevant to your post:
  53. November 13th, 2010 at 7:22am
    great post jonathan your lessons inspired me and as a basic starter that are helping me a lot thanks for this
  54. November 13th, 2010 at 8:58am
    Totally agree with you sayings.I believe that every developer who wants to be considered successful must take a look at your list!Thank you for sharing!
  55. November 13th, 2010 at 4:17pm
    Great lessons, and all true. I am totally with you on #17.
  56. hafizan
    November 13th, 2010 at 5:54pm
    ya.project never finish .that's why we got windows 7 from windows. 1.0 :P
  57. November 13th, 2010 at 10:26pm
    Nice list, thanks for sharing your experience. I'm still fairly new to programming, barely 3 years so it's good to here words of wisdom from those who have trod the path before.
  58. kev
    November 14th, 2010 at 1:03pm
    Just picking up on your point about testing, this site's layout breaks on my device. Usability testing should be just as important as functionality testing if you're developing front ends.
  59. November 14th, 2010 at 1:33pm
    Very nice suggestions.

    Thanks man
  60. shashank
    November 14th, 2010 at 2:05pm
    i totally agree with you. Amazing read!! one thing more, a client always expects that you are not only a programmers but can solve any kind of computer related problems and here your knowledge comes into play. Cos if you are able to solve them, the client-programmer relationship improves dramatically. Do not restrict your self to programming but try to gain knowledge about every aspect of computers. also point number 15 : love for music n movies should be added :D ..take care!!
  61. November 15th, 2010 at 11:26am
    All solid advice.

    Did like 'software is never finished, it's "temporarily completed."'
  62. November 15th, 2010 at 9:15pm
    I like this. 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.
  63. November 17th, 2010 at 11:50am
    Really great this post. I have a doubt related with the use of a teddy bear that mention in one comment haha but even the comments are right. These rules/ideas/experiences explained the programming life.
  64. November 22nd, 2010 at 6:06pm
    4 years later and most of it still holds true!

    Good stuff
  65. December 24th, 2010 at 8:11pm
    Great list, really. I love to read post from experienced guy like you.
  66. January 5th, 2011 at 7:18pm
    Very nice suggestions.

    Thanks man
  67. January 22nd, 2011 at 8:37pm
    Thanks, whalehead
  68. January 24th, 2011 at 5:35am
    nice great
  69. January 24th, 2011 at 10:50am
    a great share. Thank you for your studies
  70. January 24th, 2011 at 2:17pm
    this certainly is the "in your face" developer talk.. people who understand and respect this are sure to succeed.. and its true to the "T" that a software is never finished.. it's just waiting for a innovative brain to make it even better..
  71. January 27th, 2011 at 1:33pm
    Really great this post. I have a doubt related with the use of a teddy bear that mention in one comment haha but even the comments are right. These rules/ideas/experiences explained the programming life.
  72. February 3rd, 2011 at 7:05pm
    Gold content of these products, whether there are strawberries, their effects on human health is unknown, our people warn you about a debt that we know to be wary of products.

    Certainly not to the reputation of our people for their own health importance of such products would like to announce our respect.
  73. February 22nd, 2011 at 12:04pm
    I admire you for long period of programming cause my self can not stay for a long period as programmer.
  74. March 7th, 2011 at 3:30pm
    Really very nice advice. I respect your advice.
  75. March 17th, 2011 at 10:31am
    Great article you have here.. I had learned something from it.
  76. March 26th, 2011 at 9:55am
    If I want to involve my google buzz in the backlink, will it be meaningfull?

  77. April 13th, 2011 at 2:34pm
    Great lessons, I just started the first semester in our computer science university and love programming. I think that I really would like to do it in my job later and want tot hank you for the lessons.
  78. April 21st, 2011 at 9:29am
    Great list, really. I love to read post from experienced guy like you.
  79. July 28th, 2011 at 6:26am
    think it's fairly obvious that's what he meant. Anyone who's been coding long enough can get this. The point is that the code itself shouldn't be the only documentation, as many developers often leave it to be.
  80. July 28th, 2011 at 6:28am
    Sweeet! this a very helpful article!! just what am searching for! am sharing this to my friends! Thankss!
  81. March 22nd, 2012 at 5:10am
    Thanks for the information, a lot of people can use this to their benefit!
  82. June 29th, 2012 at 6:56am
    This is a good article.
    I can even relate to numbers 1, 10, 12, 19.
    I am usually guilty of solving a problem and got stuck of it for more than 7 hours.
  83. November 28th, 2012 at 5:38pm
    you are a good programmer marine.
  84. Johnycn
    June 5th, 2013 at 5:15pm
    great article~

Post a comment