• Why is my query slow?
• Why do I need indexes?
• Why isn't the optimizer using my indexes?
• Why is it important to use joins rather than putting all merge logic in code?
• Why is the database falling over?

There is no simple rule for when to do each thing. But every case I could explain why I did what I did if you understood algorithms. (And if you didn't understand algorithms, my explanation would have made no sense.)

Theres a big difference between "understanding the database" and "having the mathematical skills required to produce an analysis of the algorithms used". Nothing you listed requires the later skills. A competent DBA can answer every single question like this (and more) and not know the first thing about how to analyse mathematically the algorithms used. While your mathematical background may have assisted you in your analysis there not much there that can't be answered with rote learning and experience. A DBA or something without mathematical background probably would provide much the same answers and similar explanations for them that you have, but without the mathematical aspect. And I suspect that while the math part of your explanation may have rattled some brains (if my math skills can do that to people then im sure yours can too :-) the "common sense" and "folk science" part would have been quite comfortable with your explanation.(Ie if you say "combinatorial explosion" you may get puzzled looks, say "the number gets too big too fast" and you won't.)

Look, to be clear here, I know and understand the importance of mathematics in programming and computer science. All things being equal the more math you have the better off you are. But its a mistake to assume that because your experience of computing is so related to your mathematical understanding that others require the same understanding to do more or less the same stuff as what you do. Unless you are actively involved in algorithm research or R&D in general most of math involved in Computer Science is unnecessary. A case in point is Knuth's Art of Programming. In that book he takes care to mark and seperate the mathematical sections from the general explanations. When he goes into detailed analysis of an algorithm he does it first in laymans terms to show whats going on and then proceeds on to mind boggling stuff. I think that this organization and Knuths own comments about it being unnecessary to understand the analysis to understand the algorithms speak volumes on this subject.

---
demerphq

While there might have been a way to see the improvements I listed without understanding what algorithm the database was using and what the performance implications were, I don't know what it was. I do know that the way that I found the improvements was to actually understand what was going on. Once I saw it, of course, I could come up with simple non-explanations which you didn't need to understand the math to understand. However I doubt that understanding those non-explanations would really be useful to others.

In short I was there, I was involved, and I think that understanding algorithms was important.

You may have the opposite impression. But you weren't there.

Furthermore I have to say that I consider understanding algorithms so important that I have a standard algorithm question that I ask on interviews. It consists of showing a few lines of code, asking the person to figure out what it does, asking them to figure out why it could be a performance problem and asking for a suggestion of how to improve it. (You don't need to talk about big-O and all that, you just need to recognize that a billion operations takes a lot of time.) In general people either find it trivial (frequently they ask if there is more to the problem) or simply can't do it. (I've had people who've never taken an algorithms course find it obvious. I've had people who had it on their transcript fail.) Everyone who I had reason to think was competent has found it trivial. Most programmers that I've interviewed can't do it. I recommend against hiring the latter.

You may think that this is silly. But scaling issues have come up enough in my work that I want people around me to understand it. (More importantly, I've had enough bad experiences with programmers who didn't understand it that I don't want to get blank looks and no reaction when I point out what should be obvious...)