The first one deals with the most common programming mistakes, a few I’ve done myself. UI craziness and variable naming inconsistencies will often eat up my time as I resolve their issues.
The second article on database development mistakes addresses many of the issues I and others have with dealing with other people’s work. A missing mistake that should be on the list is a lack of inline documentation, the notes a developer should leave to not only remind them of what happened here and why choices were made, but informs future fixers of what is going on. Without these, we have to read the code like a book, and not everyone writes based upon readable standards. We spend too much time playing detective for the simplest of fixes.
A comment in the first article really caught my eye and sums up so much of what causes problems with the code.
This isn’t the tool’s fault — the error is between the keyboard and the chair. On the one hand, it speaks volumes about the quality of these tools that I trust them so much that I lost a lot of my vigilance; on the other hand, it is still my fault that I allow convenience to turn my brain off entirely. I have learned to slow myself down when using code completion and take the extra second or two to ensure that I have made the right choice.
The biggest problem is what is sitting in the chair – remember that next time you start blaming.