Earlier quoted context omitted.
There is more to math than just calculations, algebra, geometry, etc. Logic, and reasoning through choices & the effects of those choices are vital math skills as well, and for many people in math, they don't manifest until one takes a few rigorous proof-based classes, where one often sees new approaches to arriving at concepts they know, and how to properly get to a conclusion from a particular point. I wish these s…
For software engineers specifically -- every time you are coding formalized programmatic logic, you are using math. If you took a logics and proofs course, it would help you formalize logic better. Every time you write a "for" loop you are essentially using summations. There is a book called Concrete Mathematics and one of the primary authors is Donald Knuth, basically it's "Programmers math" and in my opinion, would…
I have no dislike for logic, formal proofs, category theory and such: I can live in that world just fine. However, almost none of the problems I've ever had to dealt with in my 15 years programming made me wish for large amounts of that: I've used bits here and there, but going all in never made any sense.
The hard part of most tasks I had to do in professional programming is to gather enough information to even begin to write one of those formal specifications: Knowing what real business needs are, understanding how distributed systems fail, working around bugs, reading library code quickly and effectively, learning how to factor code in a way that would evolve well with changes in what the application needs to do... that's where the value is. 99% of that is talking to people and making educated guesses about the future: The implementation itself is trivial. With that, was able to get solid code working in languages that were ill equipped to handle any of the fun pieces of math that you'd need to write mathematically-minded programs.
If anything, the experience I've had working with people that were heavy on the math has been dismal. I worked with a rather well known dev who has published books, gives a lot of talks in FP circles, and is a lead dev in a huge mathematically driven library. We worked on on a rather novel distributed systems. He hid in a corner with a copy of Mathematica for a couple of months, and came back with a paper that proved a well performing solution to one of the things we had to do with our distributed system: Great!... Except, not so, because his proof only worked in a mythological environment where there is no latency between nodes. Under real conditions, the algorithm's properties led to unacceptable results, and he just hid behind the proof.
I don't have papers and patents behind me. He knows a lot more category theory than I do. But It took me a day to implement a completely unproven algorithm that had far better performance properties in a real case. This is not due to any special brilliance of mine, but because I sat down and approached the system like a scientist or an engineer would, instead of like a mathematician.
In my opinion, teaching the scientific method and the basics of engineering in other fields will serve your average programmer far better than being better at math ever will.