Every day I'm using mathematical reasoning such as "I reached this line of code, and since this is a structured program I am guaranteed that this variable was initialized by the time I got here", "this function can only return either a non-empty string XOR an error and has nowhere it can throw an exception so if I handle those two cases I have fully handled everything this function can do", "the error string has the username in it, and values like that must come from somewhere, so even though I've been looking for an hour and can't find it, mathematically the thing generating the error message must have access to the username", "if I construct this as a pure function that does no IO, on the flip side, no users of this function will have to worry about what errors could arise during IO, reducing the mathematical cognitive load of using this function for users".
Then you start stringing together those steps by the dozens and hundreds and thousands and millions (and you get qualitative differences there too, but those don't fit into a little post like this anywhere near as well), and you can build software.
You don't have to realize you're reasoning mathematically (proof: look around), but you're leaving useful tools in the toolchest if you don't. Even if you won't believe me about building systems this way, I can assure you those magical stories about people who can debug systems at a glance that have defeated others for hours or days comes back to someone who either formally or by experience has a fairly mathematical understanding of the system in question and was able to apply some sort of logic, even if only intuitively, to arrive at that conclusion.
Programmers doing actual math would be modeling problems and creating proofs for their solutions. Usually we clasify those problems based on the field of math we use to model them.
Saying we do tons of math implies we use a lot of knowledge from a lot of those fields. But most of the time, programmers use only the introductory notions of those fields. We are usually guided by a domain expert anyway so that the math part is correct.
Programmers don't use a ton of math. They use some math.
And sure, if you define what I talked about as not math, then you don't use math. If you don't want to use the tools of mathematical thought, be my guest. It's one of my competitive advantages in the marketplace.
But I think Dijkstra would be pretty surprised to hear that structured programming wasn't math, and you might be interested in budgeting six months or so to play with Coq or something like it, where you'll learn that the difference between proving code and what you do in just trying to make code work and debug code is much more a quantitative difference than the qualitative difference you think. There's no magic in how code proofs work... it's the same processes you use all the time if you code at any scale beyond a single screen of code, just taken to their logical conclusion.
Logic is a VAST field, and most programmers don't get to use most of it, that was my point.
I already played with Coq (that feels weird to say :)) ). It is a very specialized tool useful in very specific cases. I don't think it will ever be adopted as the standard way of programming since it's really unproductive.
Just because you use math that is really heavy does not mean you understand the math behind completely. We can view a ball throw as a complex quantum-mechanical physical process but we don't call ourselves theoretical physicists for being able to throw a ball.
So there's some funny folklore regarding this...
I think this a Rumsfeldian problem: you can address the known unknowns, but what about the unknown unknowns?
There's no great answer to this, and it's why I think the original post was advocating the broad fields of math.
Just knowing math exists, though, doesn't address the depth to which you study it. I've gone at monads about five times now and I think I get it, to where I see why a promises library works the way it does. Same with databases, learned SQL, then stumbled across the wonderfully cranky dbdebunk.com, read Date's book, finally spent some months working on an implementation of the relational algebra and finally grokked it.
The problem with some of these deeper subjects is you'll have many "aha" moments only to look back at your early "ahas" and realize you had no idea what you were doing.
If your job is to write code that moves information back and forth between a database and a web page, this may be somewhat true. However, once you get beyond that to the point you are actually solving problems in code (not just moving information) you are going to need math beyond arithmetic. Algebra, boolean logic, and statistics are just a few things programmers use all the time--almost to the point that they may not think of them as "using math" because it is just built into the way they think.
Most working programmers won't have to know any math beyond arithmetic.
For instance,
"Also, how does one distribute a large computation across globally distributed data centers? You have to understand some physics to do this well: at Internet scale, the speed of light starts to be a bottleneck. Heat dissipation, density of electrical current draw per unit area, etc, are all real world considerations that go into what programmers do"
Come on, let's be real. In grade school we learned that light goes around the earth 8 times a second. That means 1/16 of a second (63ms) to go around to the other side of the world. That doesn't set a useful lower bound since this is the ballpark of latency within a country anyway. You're just going to ping between the two servers and measure the latency.
That being said, programming could in theory require any kind of math. If you're doing machine learning, you'll need to understand statistics. If you're doing graphics programming, you'll need to understand trigonometry, linear algebra, etc.
If you're writing software for the medical industry you'll presumably have to understand a little bit about how that industry works, but I wouldn't suggest programmers go learn that just for the sake of improving their "general" programming skills.
Here's a more realistic take:
1) Learn math as necessary for a field you're interested in
2) Know binary and hexadecimal representations of numbers.
3) If you're going to use a lower-level language, understand how signed/unsigned arithmetic works, boolean algebra, and some basics of the floating point representation (in a nutshell, don't assume that computations are exact, so don't rely on equality (==)).
4) Understand time and space complexity. For most programmers, this is going to be simple: don't nest too many for-loops. I'm guessing 90% of programmers will never have to construct an algorithm whose complexity involves a logarithmic function, except for maybe binary search. Even then, most programmers will rely on libraries to do those things.
5) Be able to do back of the envelope calculations, and understand that order of magnitude is more important than exact numbers. Try to do them in your head so you can quickly evaluate possibilities.
6) Increasingly, statistics and machine learning are becoming important for programmers to know. Learn some basic statistics and it will make you much more desirable. Play around with R or Octave or numpy and don't make the mistake of applying too much statistics without thinking, unless you're in the marketing department.