All of this discussion, quite possibly because so much of the initial conversation happened on twitter, embeds a lot of assumptions into the words used that seems to result in a lot of people talking past each other.
There's "programming" that's a single person essentially performing research-level mathematics; there's "programming" that's a thousand people writing to a spec without considering anything about the structure or complexity of their code. Programming is obviously not just math, nor is it no math.
If you become defensive when someone says "programming isn't math" or when someone asserts that it is, you're failing to think critically about the both words they're using and about the assumptions you're making.
Disclaimer: I have a degree in mathematics, and I'm a programmer. I can't think of the last time I used anything from my college years directly in programming itself, but I attribute a lot about the way I code and think about problems in general to having a mathematical background.
Scott Hanselman's answer is pretty good, and based on that you could say that a Coder usually doesn't know math (and in the current job market they don't need to know math to do well).
The discrete version of fast Fourier transform essentially does a matrix vector multiply faster than usual. If you are not familiar with matrix vector multiply, then think lots of multiplications and additions. Now, what fast Fourier transform does is take advantage of the fact xy + xz = x(y+z) that we know form mid school algebra. Note the right hand side has fewer operations to perform. The other thing that FFT uses is symmetry. It recognizes that two things that it needs to compute are really the same in value, so it computes it only once.
You can understand FFT without much deep math, it is just clever use of these two properties. Study it, you will really enjoy that cleverness. It is one of those algorithms that still makes me break out into a grin.
That said FFT can get more mathematically involved when you want to compute them on vectors whose lengths are not powers of two. Then it gets into primality, Chinese remainder theorem etc. However, for basic understanding and coding it you need none of these.
EDIT:
I would say dont get lost in the details, those butterfly diagrams etc. Just focus on what is the key idea that it is exploiting. There are essentially just two ideas: ditributivity: xy + xz = x(y+z) and symmetry/associativity.
May be a good idea is to sit down and derive a different way to group the multiply and adds, using those properties, to make it go fast. Dont worry if that does not beat the best algorithms out there. You will just get a better feel for the underlying mechanism.
I did implement those, but the deeper understanding eludes me. Honestly I never gave them much though, when it comes to choose whether to take a week and learn it properly I always rather code or do something tangible. Except for linear algebra, which is something I might use in the future.
> because I don't have the background, and I wish I could. Differential equations and fft come to mind.
You should just resolve learn these things and work through a section a day.
I have a math degree but never learned these things because my department was more pure than engineering oriented (an ode course wasn't required) and wanted to learn both for my day job. Turns out they are both fairly simple, and there are tons of free books. Esp differential equations have this mysticism to them before you start, and it turns out they're actually very straight-forward. Almost depressingly so, until you get pretty deep into the analysis behind them.
So... here's my encouragement to you -- just do it!
There's "programming" that's a single person essentially performing research-level mathematics; there's "programming" that's a thousand people writing to a spec without considering anything about the structure or complexity of their code. Programming is obviously not just math, nor is it no math.
If you become defensive when someone says "programming isn't math" or when someone asserts that it is, you're failing to think critically about the both words they're using and about the assumptions you're making.
Disclaimer: I have a degree in mathematics, and I'm a programmer. I can't think of the last time I used anything from my college years directly in programming itself, but I attribute a lot about the way I code and think about problems in general to having a mathematical background.