Edie Montreux
But WHY?
I've never been that girl. The one who has to know why or how something broke. The one who has to understand the intricacies of how we got into this mess. That's not me.
When I'm explaining how I broke something and then how I fixed it, I am not the person to ask, "But WHY did it break?"

I'm never prepared to answer that question, and someone always asks. "I don't fucking know, Chad. Instead of worrying about the inherent bug in the source code, let's concentrate on not triggering the bug again, shall we?"
It amazes me sometimes that folks want to know why some buggy code exists within an ancient buggy program. The program was built by humans who didn't know what they didn't know, so they didn't test for this particular problem. The code did what they needed it to do. We add some random new code to the mix, and boom. Broken. I don't need to know what piece of the source is interacting badly. We'll probably never find it. We don't have the funds to fix it, even if we did. We are a small consumer for a giant product, and it's not a big deal to switch one little symbol. I'm just grateful someone found our bad code and gave us the fix.
I know I'm talking a lot about code here, but the problem isn't code-related. It's brain related. Some people would rather focus more deeply on the problem than on how to fix it. I don't need to know why it broke, or when it broke. I just need to know how not to break it again. This makes me a fast, efficient coder.
It also makes me a shallow human with few meaningful relationships.
