Circa 2000 (a lifetime ago in this business) — I was supporting an application I developed at First Union (before it became Wachovia and eventually Wells Fargo). Say what you will about the big banks (and I have my own set of concerns) — but Bank of America and all 3 versions of Wells provided me with a wealth of opportunity.

What a privilege to get paid to solve problems. For that reason and others, I’ve always felt a great responsibility to all those attached to my livelihood.

So one day a colleague calls me up and says, “I think I’ve done something wrong — I’m getting an error.” I replied, “First off, let’s get something straight — there’s no such thing as a user error — it’s always the programmer’s fault.”

Of course, there are caveats to that rule, but as a guiding principle: Anything that can be anticipated—should be!

It’s that very mindset that makes me start my troubleshooting at the source. That brings to mind an SSRS report that was handed over to our team at Medxcel and I was asked to look into the performance problem. It was taking 28 minutes to run and I was told that the user was unhappy about it (and rightly so). One of my colleagues met with the original developer to get some background on the issues, and I was struck by the bullet list of beliefs that he provided her (none of which had a hint of self-inquiry).

Apparently the user has a “history” of being “demanding” in her data needs, so the developer’s recommendations all revolved around her cutting back (# of columns, date range and such).

Whether or not she has a “reputation” is irrelevant to my mandate. Maybe she is asking for too much data . . .

Or

It might be the way the report was written — maybe we should start there instead of being satisfied with assumptions? I took one glance at the code and could see the likely culprit, and my detailed investigation confirmed my suspicions.

A day and a half later I had it running in 2 minutes.