In programming, you may never use that stuff at all. Sure, I've used some dot/cross product, plane equation, etc. in my game development, but in my professional experience (business apps) I've never used more than basic arithmetic.
Actually you can model quite easily and very efficiently with math in programming regardless of what you are doing, you can easily make your entire application a collection of mathematical equations. Then again you can model anything, math can be applied to everything and be useful too. Computers are really powerful calculators and everything you see or do has some math behind it, making it easier to apply regardless of the project and it can actually be a fun way to move away from the traditional 'physics / engineering / finance' approach to calculus.
Play around with an OO functional language focusing on equations for a while and you will probably quickly find many ways you can apply calculus to your business apps and almost all the areas wont be obvious either.
reminds me of something that came up a while ago, and became a point of contention:
as I see it, computers don't run on math;
this doesn't mean math isn't involved somewhere, only it is not what actually "runs" the computer, but rather, it is much closer to running on mechanisms implementing basic arithmetic with an algebra-like abstraction layer thrown on top, but even then it is weak as many core assumptions made in algebra and calculus don't really map over to computers, and with most of the actual "math" part being done by the human programmer (and not by the computer).
but, then again, I am left to realize that this basically comes down to worldview.
actually, I guess this brings up another point:
actually knowing what one is doing, and thus designing something more based on the relative design tradeoffs of the various options;
not really knowing what they are doing, and just sort of hacking on it in an attempt to get a desirable result (basically, lots of fiddling and trial-and-error trying to better approach the desired results).
I guess, arguably the "engineering" in software-engineering, is probably more in reference to when someone knows what they are doing (and weighs various options and similar), rather than just hacking on it in an attempt to make it work.
interestingly, both seem to have pros and cons, rather than one strategy or another always producing a better result.
it seems to depend a lot on what someone is doing at the time.
other times, a person may need to "just do it" regardless of whether or not they really have all the prerequisite knowledge.
like, "there is only me, and I don't really know how to make this, but there is no other way it is going to get done" (leading to it being time to break out the trial-and-error and prepare for extended periods of fiddling...).
or such...
