Developers should care and feed for their systems, especially when they’re in production. Alerting, logging, and metrics are the tools you need. Further, you need to use actual production errors as a feedback loop to push you to write more fault tolerant code.
I’ve struggled with that part in the past. It’s tempting to think I can just code along, building beautiful code. Beautiful code is entirely different from production code. Handling errors, timeouts, partial failures, logging, instrumentation: it’s not exactly design pattern stuff. To wit:
Fault-tolerant code is ugly. It requires conditionals. It won’t look like code in programming books, screencasts, or blog entries. This is the way it has to be, I’m sorry.
Production is all that matters. Highly intelligent words from Dave Copeland. The beauty of code, as it appears in my text editor, is not as important as how it works when it runs on servers. New mantra!
Adam Keys is typing 
I know it sounds snarky, but I’m actually serious when I ask: what patterns books are you talking about? Because the ones I read are full of that stuff… after all, they are written by people solving the same production problems you and I and Dave are solving, over and over again.
It sounds snarky because you didn’t cite any examples :P
Talking about conditionals as if they are somehow antithetical to beautiful code is… weird. But if your high-level domain logic is littered with repetitive low-level error-case handling, you’re not doing the people who fight production fires (e.g. you) any favors.
That’s fair. Nygard’s “Release It!” comes to mind. The POSA books are littered with patterns for dealing with highly error-prone concurrent IO, as I recall. PLOPD1 contains the CHECKS Pattern Language by Ward Cunningham, one of the most thought-provoking explorations I’ve seen on dealing with the crappy broken input those annoying users throw at you. The concurrency section of PoEAA, while short, is absolutely essential reading for thinking about production concerns.
I agree wholeheartedly that production enterprise code absolutely must incorporate logging, metrics, error handling, etc. I disagree firmly that these requirements necessitate ugly code. Beautiful production enterprise code should incorporate logging, metrics, error handling, and the like as explicit actors in their systems.
Where I think we sometimes go wrong is in *not* modeling these concerns explicitly, test-driving their development, treating them as an afterthought. When you do that, you’ll get conditional, unspecified detritus scattered hither and yon. But that can happen with any dependency.
The last ‘graph, a thousand times.