[tnecniv]

>I highly doubt most programmers need to know how to do formal proofs of algorithms, determine asymptotic complexity of algorithms, or even know that much about data structures.

Indeed, but I believe that having a solid foundation in theory is important. People have spent a lot of time coming up with ways to reason about common problems, and you don't need to reinvent the wheel.

Additionally, while many programmers can get by with skimping on theory, your mathematical knowledge tends to limit problems you can tackle. While you might be able to get away with making some CRUD application without applying any complicated math, you will have a hard time trying to write code to localize your robot with SLAM. Knowing theory only opens more doors to more interesting problems.

[rickycook]

sure, but the maths involved with building a robot is not the same as doing user analytics etc. better to assume no knowledge when entering those fields, and learn on the job otherwise you learn a whole load of stuff you'll never need. you can't be a senior in a field you know nothing about, so these jobs will always have someone that knows that stuff and can pass on their knowledge.

i can say for fairly certain that 90% of the engineering maths i did at uni will not be applicable to me in my career, and there's plenty of maths that would be applicable that i wasn't taught. considering that was a 6mo unit (and ignoring the fact that it was easily the one that burned me out fastest), that's a lot of wasted time.

[tnecniv]

The engineering math curriculum has issues, yes, I agree. I thought a lot of topics were taught in the wrong order and their usefulness was often not made clear until much later. At this point, though, I think I've used techniques from pretty much every class (even ones I thought were irrelevant when I took them) I took.

But really, the engineering math curriculum has (or at least should have) three purposes. The first is to teach you logical reasoning and problem solving -- critical skills. The next is to provide you with a toolbox of techniques you can call upon to solve common problems in your field. Finally, the curriculum should provide you with the mathematical maturity to acquire the new mathematical tools that you need.

The last point directly relates to your second paragraph. I don't know very much about data analytics. If I (somehow) got hired into a big data role, the senior engineers will lack both the time and the desire to sit me down and give me the background on statistics, machine learning, etc. that I would need. However, because I have spent a lot of time studying other mathematical topics and have a background in linear algebra, probability, etc., they can point me at good sources and I can learn myself. If I came in just knowing single variable calculus from high school I would have a rough time.

[agentultra]

I agree!

Except that I think formal mathematics and proofs are attainable by informally-trained programmers... just perhaps not computer scientists.

To quote Friedrich Bauer:

"Software engineering is the part of computer science which is too difficult for the computer scientist."

I'm not sure how true that is. I don't have a computer science degree. I just have some interesting anecdotes from a colleague who is pursuing his Ph.D in computer science with a focus on developing a formal proof system. As a teachers' assistant he gets to run some classes. Most students tend to snore through formal methods I'm told. In order to wake them up he asked his students, who are working on their masters, to implement binary search. He gave them a specification for the algorithm and off they went in pairs. He used the PlusCal language from TLA+ to model around eight submissions in roughly two hours (I'm not sure what the exact number was). He found errors in 7 of them and was able to demonstrate what the inputs were and the steps the algorithm would take to reach the error state thanks to the model checker in the TLA+ toolbox. He got a few students hooked from that point.

In my case maths is exactly what I needed. I'd been working in distributed systems for years without an iota of training in formal methods. I'd read Leslie Lamport's papers on time, Paxos Made Simple, Raft, Bloom^L, etc. I have several common textbooks on distributed systems. I'd worked my way through many subjects in graph theory, "concrete" mathematics, discrete maths, etc. But as Nathan says what saved me most was experience and learning what abstractions to use and how to maintain a handle on complexity. If I just followed the code I could make things work. Except when the code wasn't a good enough abstraction (in the mathematical sense)... then things got hard (ie: race conditions, scheduling problems, etc). I used to just follow the code and suss out the problem using standard debugging tools and time-honored techniques but what started to really click for me was modelling my problem in TLA+. When I started leaning on maths I felt like I could start achieving more and solve problems before they became bigger problems.

I often talk about programming as a force-amplifier. If you're an actuary and you know how to program you will be a better actuary than your peers. Maths is the force-amplifier for programmers. You can learn formal mathematics and create a language for modelling computations that you can prove. Anything you can do from there will be better than what your peers can do.

... and yes I realize that not every piece of software needs to be accompanied by a proof. But for the hard problems it's a useful tool to have. And there are many other subjects where it's becoming necessary to understand different branches: graphics, AI, "big data" (ie: applied statistics), distributed systems (even your modern processor is a tiny distributed system), etc.