Yeah, I'm with you very much. There's a very clear distinction between "the foundations" of programming/software development, domain-specific expertise, and language/platform expertise. The foundational pieces are pretty much timeless; the platform pieces are ephemeral. Getting good at the foundational pieces ("the maths" as you call it) is a total game changer for being able to sit down with some new/unknown library or codebase and get to a level of understanding quickly.

You had me at numerical algorithms but I'm not sure I agree about functional programming and type theory. I used to like functional programming and type theory when I was younger and found it completely useless as I moved further along in my career.

I'll make a different suggestion: set theory (which builds intuition around relational data modeling) and distributed systems (which builds intuition around building scalable services and software architecture) are by far the most important theoretical foundations I've had to actually apply at scale. That's followed by data structures & algorithms and discrete mathematics (for the rare times I really do need to write some optimized inner loops).

I don't want to be dismissive of set theory, because it has an extremely rich History and is still seen by most as the foundation of maths, but I believe there are some fundamental issues with it that make type theory a more appropriate foundational choice for general computation and programming language theory/design. There's a reason theorem assistants and proof languages are based on some version of type theory, rather than set theory.

To a first approximation, type theory and set theory play similar roles. There has been a lot of noise in recent years around replacing set theory with type theory as the foundation of maths, at least in the context of proof assistants and programming language theory.

But nonetheless, I agree that knowledge of set theory can't hurt (and practically speaking, you can't go far in your maths journey without it).

(I would also note that functional programming is a special case of relational programming.)

But when is the average engineer going to need to deeply understand functional programming vs needing to deeply understand SQL? The latter governs how your data is stored and mutated at rest while the former, while an influential flavor of programming, is ultimately not the model that won out in the market (and for good reasons IMO).

Most of the volume of useful work to be done in programming is about state manipulation, which is mostly relational database operations, which is mostly about set theory.

I think every engineer should learn foundations that best equip them for the market long term, and prioritize their order of attack along those investments which will earn them outsized value. Data structures and algorithms, set theory and distributed systems equip an engineer extremely well for that.

I have a very hard time believing deep investments in functional programming and type theory would differentially pay off better.

Now, if one's goal is not to optimize for the market, then I think the answer is a lot more broad.

Arguably, biochem also has "solid foundations" in physics. Would you recommend someone in your field to "follow the physics" in their journey?

Yes. Also follow the chemistry, and follow the maths.

Any answer other than "yes" falls squarely in the anti-intellectual category... But of course all the usual pragmatism applies unless you are a point particle having indefinite lifespan.

> the usual pragmatism applies

That sounds like by "follow" you don't mean "study a lot"... What do you mean then?

I think you're putting words in my mouth. I meant everything I wrote literally and there was no subtext between the lines.