Obie is Founder of Hashrocket, one of the world's leading web design and development consultancies. He is a widely recognized technology leader and frequent speaker at industry events and is Addison-Wesley's Series Editor for the bestselling Professional Ruby Series. Prior to Hashrocket, as a senior consultant at ThoughtWorks, Obie specialized in complex custom enterprise software projects. He has been hacking computers since he got his first Commodore VIC-20 in the eighties, and found himself in the right place and time as a programmer on some of the first Java enterprise projects of the mid-nineties.
The following advice may seem bloody obvious, but too often I must remind myself and others of it: "Take a moment to understand the error message at the top of an exception/stack trace before making additional changes to your code." I'm not quite sure why it's so difficult to follow this advice, but over the years I have gathered some clues. First of all, unless we're hacking code for pleasure, we're always under some amount of time pressure. And when we're making tweaks to some code, we generally have at least an inkling of what will work and what won't. We often take a stab at a solution and make additional code changes, without fully understanding what the effect will be. Then you flip back to your program or test console to see the result of the change, and once again there are dozens of lines of a stack trace filling up your terminal buffer. The actual error message will almost never be immediately visible.
At that brief, almost instinctual moment, you have a choice. Scroll up to the top of the trace and see exactly what went wrong, or, assume what went wrong, jump back to the code and try something slightly different. I guess it's human nature, or perhaps how much caffeine we've taken in that day, but so often it's tempting to jump on your assumption.
I've especially noticed this bad habit in beginners, during pair programming sessions. I believe it's because when we're learning to program, we make so many mistakes. The resulting insecurity causes us to make small corrections as quickly as possible. In my experience, it's always more efficient to see what kind of error or failure we're dealing with instead of jumping straight back to the code and attempting to figure it out in our heads.
So always take a moment to scroll up and take a look at the actual erorr message at the top of your stack traces. Too often your first instinct is completely wrong and by charging off in ignorance you waste much time and effort.