First off: I am a mathematician - a professional one (in that I get paid for doing maths). I am not a programmer. I do do some programming, but very definitely of the Cargo Cult variety (see first comment to https://tex.stackexchange.com/q/451/86 and my response) and nothing of the sort that would normally bring me to this site (indeed, I registered here to post this answer after seeing a link to it in the TeX chat room).
The summary of my answer is: Mathematics is Programming.
I recently got to teach a mathematics course to a non-mathematical group of students. They were the programming section. I thought this was fantastic! At last, I was going to be able to teach mathematics to people who already understood the basic ideas and who already had a rudimentary toolkit for doing maths. I was incredibly disappointed when I asked how many of them had actually written a program and got an answer somewhere between 0 and 1.
Before I go on, I should clarify a few things. There are areas of mathematics that concern themselves directly with programming and are to do with evaluating algorithms and classifying languages and such-like. I'm not talking about those. There is also a program which is trying to translate all of mathematics into a formal language that can be evaluated by a computer. This is a bit closer to what I'm talking about, but even so to focus on that would miss the main part of what I'm trying to say. The mathematics that I do and the programming that I do are almost completely unrelated by topic. The connection between them is on a different level.
Where I'd like to start is with the comment on the main question:
If that is doing math, then all human activity is a form of math. If that's the case then the word math doesn't have a useful meaning, because it can't be used to distinguish one activity from another.
Yes, that is doing maths. But "maths" is still a useful word because, as the song says, "It ain't what you do, it's the way that you do it.". I would say that I am doing maths when I am approaching something in a mathematical way. Sometimes, that is "hard core" mathematics: formulating definitions, proving theorems. Sometimes, it isn't. Sometimes, it's writing silly little programs so that my kids can learn their spelling words.
This is what mathematics helps me with when I program:
Abstraction This is probably the most important transferable skill from mathematics. By this, I mean the ability to strip away all the unnecessary stuff and focus on the important properties.
Perspective If I could only choose one thing that all my students were to learn, this would be it: The ability to change ones point of view to suit the problem. We commonly treat this in linear algebra with change-of-basis formulae (that lead to horrendous matrices and horrendous complications), but it is much more applicable than that. At heart, it is the idea that just because something has been presented to you in one fashion, that doesn't have to be the way you work with it. This separates ones view of the thing itself from the way it has been presented. This can be extremely practical: it is all about making something useful or efficient. If I have a list of vectors and it is more efficient to store them as a list of x-coordinates and a list of y-coordinates, so be it.
Form versus Function Leading on from the above; if a thing can be presented in many different ways then it is no longer fair to say that one particular presentation is the thing. To misquote that song again: "It ain't what you are it's what you do" that matters.
I could go on, but those are the ones that spring to mind.
Now, there are probably lots of (negative) reactions to what I've written so far. One will be "That's not maths, that's just good sense." (or bad sense) to which I refer to my remark above agreeing with the sentiment that "all human activity is a form of math". Another will be "That isn't the type of maths meant in the question.". This is almost certainly true and here I actually have a lot more sympathy with the person who said "At least I haven't touched the maths for 10 years,". He or she is wrong, of course, they have been doing maths for 10 years because whenever they wrote a program they were doing maths. They just didn't realise it. And here we get to the point about why I was delighted with the (sadly unrealised) possibility of teaching mathematics to students who were already programmers.
I do actually use some "real maths" in my programs. I recently coded a fun 3D shape explorer which involved using some maths to figure out the projections and other transformations that I had to apply to my data. I was mildly amused to find myself actually coding quaternions! But of course, the maths that was involved was trivial compared to the maths that I do when I'm working. It was "back of envelope" stuff. That type of maths, then I agree with the sentiment that you pick it up when you need it, and if you need something more complicated than you can find on Wikipedia then you find a real mathematician to do it for you. However, in order that you can pick it up when you need it then you need to have learnt something. That thing might not be anything you ever actually use, but having learnt that something makes it all the easier to pick up what you do actually use later in life. So this is where I disagree with Coder: you do need to learn some mathematics if you are ever going to use any mathematics and you need to learn it from the mathematical side (which doesn't mean proving theorems, by the way).
And so finally to the "Mathematics is Programming". You can learn all of these things from being a good programmer. And if you've learnt these things, you will find mathematics much easier because you will understand that when we talk about a vector in a vector space then it's just an instance of the class
Vector which means that we can do all the things that
Vector does to that instance: add, subtract, scale, and so forth. That's why I would love to teach mathematics to programmers. But, speaking as a mathematician, I would say that the first of these, "Abstraction", is easier to learn in mathematics than in programming because mathematics is the pursuit of abstraction. Whenever we see some behaviour our training is always to ask "What is it about that thing that makes it behave in that way? What if I took another thing that was similar, would it behave in the same way? How much of what that thing is would I have to lose for it to stop behaving like that?" (Taking this to the extreme leads to "centipede mathematics" - search for the term). But we don't do this with (just) "real world" objects (whatever they are), we do this with things that have already been abstracted.
This has gone on long enough, so let me close with one of the classic mathematician jokes:
A mathematician and a physicist both attended a seminar on some new model involving 24 dimensional space. Afterwards, they were discussing it and the physicist remarked: "That was really hard. I mean, how does one visualise 24-dimensional space?" to which the mathematician replied: "Oh, it's easy. Just visualise n-dimensional space and then set n = 24.".
There were quite a few comments on this answer expressing a variety of views. These have now been deleted by a moderator on the understanding that I would try to take into incorporate them (or respond to them) in my answer.
However, I'm not sure that I can. Reading those comments and the rest of what's on this page, I can only come to the conclusion that there is a huge misunderstanding as to what mathematics actually is. Moreover, I don't feel competent enough to explain it. Fortunately, someone has already linked to Lockhart's Lament so I'll defer the explanation to that. Whilst I might have put it differently (as I grew up in a scientific environment, I would have put more emphasis on the experimental nature of mathematics), I don't think I could put it better.
I do still think I can add something. As well as the misunderstandings as to what mathematics is, there are also misunderstandings as to what "doing mathematics" means. I see two almost contradictory stances:
Mathematics is about equations and formulas. So there's no need to study it because Wikipedia exists (this is almost the converse of Euler's apocryphal challenge to Diderot).
Mathematics is about theorems and definitions. So there's no need to study it as programs never prove anything (which is about as complete a fallacy as ... insert favourite fallacy here).
Whilst the two stances contradict each other, they end up in the same place: there's no point in a programmer learning any mathematics - and most assuredly not from a mathematician! After all, what do they know about anything? Anything that a programmer really needs to know can be found in Wikipedia, or cribbed off someone else.
Above, I described myself as a Cargo Cult Programmer. I bet most of you had a private giggle to yourself and thought, "Ah yes, I bet I know what your programs look like then.". You probably felt a bit smug and superior (though I'm sure you felt bad about feeling smug and superior).
What I've described just above is Cargo Cult Mathematics.
So when I say that you should learn a bit of mathematics to understand how mathematics works, I'm saying it for exactly the same reason as you might if you saw a bit of code that I'd written: "How much easier your life would be if you'd stop cut-and-pasting code from StackOverflow and learnt just a bit about how to do it properly.".
The most important thing, though, is that you should learn it from mathematicians. Why so? Here's an analogy. The language that I'm most adept at is TeX. (Says it all, really!). Now, suppose I want to learn a bit more about TeX and it just so happens that Don Knuth is in town and has offered to give some tutorials on TeX. Or I could just read about it on Wikipedia. Or maybe it's Perl and Larry Wall, or C# (is that the right one?) and Jon Skeet. It may well be that these people are not the best teachers, but they sure make up for it in the amount that they know!
And that's what mathematicians are. We're the people who write the actual language, who then write the libraries that you use. Of course, you don't have to know how to prove a theorem - you're not going to write a library! But if you know a bit about how we think, then it might help you understand why we wrote the library the way we did, and if you understand that it might help you make better use of it.
There is a middle ground between looking up equations on Wikipedia and proving the Poincaré conjecture, just as - to refer to Lockhart's lament - there is a middle ground between "I don't really know much about art, but I know what I like" and being Monet, and between "Where's the 'ANY' key?" and being Don Knuth. If you are still in university then you have an amazing opportunity to learn from people who are experts in their area and who - for some reason - are willing to spend their time explaining it to you.
The other point I wanted to expand on a bit was why as a programmer you should not be scared of learning a bit more mathematics. It's not the Deep Connections, nor the usefulness. It's that your ability to program a computer can directly help you learn mathematics. I just want to mention a few.
Understanding variables. So many people get confused by simple statements like "Let n be a natural number ...". Or "Let epsilon > 0". There are places in mathematics where it's important to remember the scope of a variable. These are all commonplace in programming. Learn to translate a mathematical statement into a program and you'll find it much easier to keep track of what's what.
The nature of proof. If you've ever written a test, or written a program to be used by someone else, then you understand the core of proofs. When you do that, you have to know that whatever the user puts in, you can deal with it (insert obligatory xkcd reference here). That's all a proof is! A demonstration that whatever the "user/universe" puts in, the statement will hold. Experimentalists will lean to the "If it works under normal circumstances, it's true" but programmers know that there is always that kid who will try Alt+G+Shift+ÅØÆ just to see what happens.
DRY. Sorry to break this to you, but we invented it, not you. We've been "not repeating ourselves" for millennia. That's why I have a copy of Euclid's elements on my shelves and it's still useful.
And there's more. If I knew a bit more about programming, I'd write a book called "Mathematics for Programmers" where the aim wasn't to teach "The mathematics that programmers should know" but "mathematics that everyone should know, but optimised for programmers". But I'll probably never know enough about programming to write it - unless someone offers to collaborate with me!
I'll leave it there. Probably if I thought more, I'd change what I've written; hopefully I'd explain it better. In a months' time I might even disagree with parts of it. If anyone wishes to argue further, or comment otherwise, probably best not to do so in the comments here. You know where to find me.