Most of the structuring (and, therefore, syntax) around an 'enterprise' application, is about how easy it is to 'replace'/'change' functions based on future needs (or known, but yet un-realized requirements).
In mathematics, the driver for notation is:
how succinctly can I express, what I want to express in this particular effort, yet allowing others to verify my work without mis-interpretation.
I am not sure if those two worlds are reconcilable, and mergeable, with worlds of structured and 'just-in-time' teaching.
I am going to also, claim, that style of presentation of mathematics is more appropriate for formulating vision, structure, strategy, architecture in formal technical/financial 'contracts'.
As I progress (perhaps, already at a sunset) of my career, I can see that lack of fluency in mathematics (both algebra and analysis) is a major impediment for transition into more highly compensated (and impactful) , yet, still technical roles for many of us, out there.
> As I progress (perhaps, already at a sunset) of my career, I can see that lack of fluency in mathematics (both algebra and analysis) is a major impediment for transition into more highly compensated (and impactful) , yet, still technical roles for many of us, out there.
Do you have an example off the top of your head? I'm assuming that by, "fluency in mathematics (both algebra and analysis)", you mean something beyond basic calculus and linear algebra.
My experience has been that software engineers at the staff, principal and architect levels don't really need to know advanced mathematics at all. From what I've seen they usually have a breadth of experience as generalists and a depth of experience in one or two particular specializations, which may or may not involve any advanced mathematics at all.
> mean something beyond basic calculus and linear algebra.
"Fluency" in mathematics, in my experience, isn't about being able to perform more complex computation, that's what computers are for. The key to fluency in mathematics is increased efficiency at equational reasoning.
Granted, I work in data science, but I've personally seen that more and more problems I have are solved writing out a few equations and reasoning about the problem than writing code. It's not about knowing, for example, what SVD is, but seeing how a variety of common problems trivially map to it. Or figuring out how to transform a business problem into a probability problem so you can quickly estimate your success. Many times now I have spent a few afternoons writing equations that simplified what would have been very large and unnecessarily complex programs.
The mistake programmers make is thinking that math is just fancy computation, but mathematical reasoning is an entirely distinct way of reasoning about problems and computation is usually the least important part.
I used to also think that there was no reason for programmers to learn any math outside of enough calculus and linear algebra to compute basic things. But really understanding these areas and reasoning about them fluently (as well as other areas of mathematics) opens up many possibilities of problem solving that code it self does not.
1) Modeling capacity/latency of complex system with queuing theory (basically creating spreadsheets that can 'calculate' how much servers you need with what I/O throughput/etc for our software)
2) When looking at tables in data-warehouse, as 'types' -- I felt I could benefit from leveraging modern type theory, where I could at least categorize schemas (filds/relations) into 'Automatically-transformable into target warehouse schema' vs 'human intervention is needed'.
Besides natural complexity, the papers in type theory use that fraction notation :-). For some reason difficult for me.
3) Various data de-anonymization proofing techniques, differential crypto, and tamper-proof logging.
Ability to read financial mathematics and NLP technique is something I do not need now, but I would have benefitted significantly in my past.
In mathematics, the driver for notation is: how succinctly can I express, what I want to express in this particular effort, yet allowing others to verify my work without mis-interpretation.
I am not sure if those two worlds are reconcilable, and mergeable, with worlds of structured and 'just-in-time' teaching.
I am going to also, claim, that style of presentation of mathematics is more appropriate for formulating vision, structure, strategy, architecture in formal technical/financial 'contracts'.
As I progress (perhaps, already at a sunset) of my career, I can see that lack of fluency in mathematics (both algebra and analysis) is a major impediment for transition into more highly compensated (and impactful) , yet, still technical roles for many of us, out there.