Note--I didn't ask if your code worked, or if your code was in production. I asked "Is your code Operational?"
When you develop code, you have the advantage of having a debugger and compiler on hand. When something isn't working correctly, you set some breakpoints and begin debugging your code. But what about when you move to Integration, Test, QA or Production (or whatever you call it).
Here's the real question--do you have to recompile your code to know what's going on? It sounds crazy, but if you have to go back and put Response.Write or Debug.Print or alert('Here') in order to debug your code, you aren't finishing the job.
Operationally, you need to implement tracing, logging, performance monitoring, etc. in order to really consider your work complete.
What? You aren't doing that? You don't think that is necessary? OK, that's fine. You spend your time coming in to the office, putting code in, recompile, repush, find the problem, fix the problem, take the code back out repush, repeat...I'll spend my time working on better things.
There are a plethora of tools to support you--log4net, debugger listeners, Microsoft Enterprise Library, PerfMon, etc. Spend some time this week reading up on it.
Note--Yeah, I could have provided links here to all of that stuff, but if you care that much about learning, the extra effort for you may help you find other alternatives.