I don’t care if you like Hungarian notation, camel case, Pascal case, or whatever, but you have to be consistent — and not just with your casing but with the naming. For example, if you are passing around a Customer Number, do not call it “custNo” in one place, “customerID” somewhere else, and “custNum” in a third place. Each version keeps the same case, but each one appears to be talking about a totally different piece of data. This makes maintenance very difficult.
2: Date/time issues
I recently read a piece called “33 myths developers have about dates and times” or something along those lines, and the very next day I had to solve a bug because a previous developer on a piece of code persistently misunderstood if noon was “AM” or “PM” in the 12-hour format. I can’t stand on the high road here, because I have made plenty of poor assumptions when it comes to date and time issues. I learned that you should not try to do these things yourself, and instead leverage your language’s built-in date/time functions.
3: UI craziness
Every now and then, a UI idea, component, widget, or style will suddenly come into style, and the next thing you know, it is everywhere. This is fine when it is a simple matter of aesthetics, but when it comes to actual UI functionality, step cautiously. A good example is the massive menus that have become common on websites. While the menus may solve a common development problem, a lot of developers use them inappropriately, or push them onto an audience that do not understand them very well, and the result is a bad user experience. A similar issue is the use of certain UI metaphors that can be confusing to users, like drag and drop or the use of trees. These items are perfectly fine when used in moderation and in the right areas, but some programmers develop an infatuation with them and use them in all sorts of wrong ways.
4: Not checking the logs
I cannot tell you how many times I have heard a conversation that went like this:
Programmer A: Can you help me with this problem?
Programmer B: Sure. What kind of error message are you getting?
Programmer A: I don’t know.
Programmer B: Have you checked the logs?
Programmer A: No.
If you haven’t checked the logs to get the error message, how do you expect to find out the problem that needs to be fixed? A similar situation is when developers don’t take the time to find the error message in other ways. For example, if something isn’t happening in your Web app and JavaScript is involved, there is a good chance that a JavaScript error is preventing your browser from running any more JavaScript on the page. Simply opening the F12 tools in IE or Chrome, or Firebug in Firefox, and watching the JavaScript console for errors will likely put you on the right path.
5: Overdependence on code completion
I use a lot of tools that perform code completion. In a typical work day, I spend at least some time within Visual Studio and getting to use IntelliSense, and for the bulk of my day I am head deep into Agile Platform’s Service Studio, which takes code completion to new levels — not only does it fill in and offer suggestions as I type, but in many places it automatically offers a list of things based on the type needed and what is in scope. This is a fantastic feature, but once in a while it bites me in the rear when I blindly take the wrong item just because it is at the top of the list or because it looks close enough to the actual choice I need. 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.
