Mitch Wheat - Treat the cause, not the symptoms!

Are you setting out on your programming career? Do you want to be a better programmer? Here is a very short, set of guidelines (there’s nothing really new here, and it is not comprehensive, but if you are already following the majority of these then you are on the right track):

• Be Consistent. Be consistent in everything you do. Periodically, examine the way you do things and the reason you do them that particular way; periodically re-assess to see if there are better ways.
• Always name things as accurately as possible. If you find yourself unsure of how to name something, then you are probably unsure of its intended use. In the case of a class, it is often an indication that you should break it into smaller, multiple classes.
• Always put yourself in the role of the user (= consumer). This Zen-like approach is ubiquitous: always design things from the point of the view of the consumer, regardless of who (or what) the consumer is. This includes frameworks, UI, objects, methods; basically everything! If you want an alterior motive, that consumer might be you in 6 months time!
• Great software takes into account People, Process, Business, and Technology in that order.
• Expect and design for CHANGE. Well designed software is flexible and resilient to changes in requirements. BUT do not over design. The art is in finding the right balance.
• Never ‘invent’ your own encryption or random number algorithms (there are some classic coding horror stories of programmers rolling their own. This is an excellent article if you can find it: S. Park and K. Miller. Random number generators: good ones are hard to find. Comm. ACM, 31:1192—1201)
• Never use Bubble sort! (and that means ever!) (see my previous blog entry)
• Always use ISO date format when outputting dates as strings. This site is highly recommended reading.
• Use and believe in testing. Use Nunit (or your platform specific xUnit) for unit testing. Watir is a good candidate for web UI testing.
• The majority of runtime bugs/problems encountered are usually related to:
  (1) Permissions and Roles
  (2) Dates and Date Formats
  (3) Timing Issues
  (4) Configuration (which includes the previous 3 points)
• When you have the choice of scripting a sequence of actions or just using an IDE tool to implement changes in an ad-hoc manner, ALWAYS script, script and script again!
• When you are unsure of how something works, ask someone. There really are no stupid questions (only the ones you needed to ask but didn’t!).
• Get a mentor (if you can). Either a senior programmer where you work or someone online. The online development community has flourished in the last 5 years and it abounds with talented people that give up their time to share best practices, such as Agile or Test Driven Development.
• The software industry is somewhat unique with regards to the rate of change: if the thought of continuous change coupled with continuous learning throughout your career seems un-appealing then you should probably look for another vocation!
• In my experience, the developers that write the fewest bugs tend to be the ones that have the smallest egos. When a bug is found in an application that includes your code, assume the bug is yours (within reason) and take responsibility for it. If it is yours it will probably be easier for you to fix than someone else, plus it is always easier to find out it is actually due to code written by someone else (help them fix it, the problem is still yours!), then to look foolish by pretending the problem lies elsewhere only to find it was you who made a silly mistake
• When converting code between languages, be mindful of ‘off by one’ or boundary condition errors, as some languages have 1-based arrays by default. (I was going to remove this point as I wasn’t sure it was still as relevant, but having just found a subtle bug in converted code, I’ve included it).
• Get closure on problems: bugs do not just go away! I have heard programmers actually say “Oh that bug?, it just went away!” This may be an indication that you are in the wrong profession! One trait that distinguishes good programmers is a burning desire to get to the root cause of problems.

Early last year (2005), I wrote a Powerpoint presentation that discusses steps you can take towards becoming a better programmer. I’ve delivered it at 2 companies, and it was well received. If anyone is interested, let me know and I’ll post it here.