[adamcharnock]

I think this is possibly the crux of it for me. I've certainly got well developed abstract thinking for software development, but software has always had a clear application for me, so the abstract thinking developed as a matter of course.

I've rarely found any higher math instruction which takes for the form, "so you have this specific problem X, here is how we can solve it with technique Y"[1]. But I suspect that it is because it is higher math (which presumably means 'higher order' math).

Without this, and without an inherent enjoyment of the pureness of the math, it seems somewhat esoteric for me personally. I'm not complaining, nor do I really think it should be any other way. I'm just reflecting on it really.

This also makes me think of my foray into monads: "The thing about monads is once you finally understand them you immediately lose the ability to explain what they are to others." Not saying that's the case here, just feels related.

[1] At least where I found problem X to be satisfactory. I didn't find my lecturer's problem of, "you're stood on a mountain described by this PDE, on what vector must one walk in order to stay at the same altitude" to be very applicable. I was a pretty wilful student though.

[vecter]

Software development never gets that abstract. Yes there are abstractions, but compared to college math, they're extremely simple. The most complex abstractions I've come across in software engineering don't hold a candle to some of the abstractions you would see in a typical undergraduate math degree. Heck, my university used Baby Rudin [0] for its introductory analysis class, which was often taken by freshmen or sophomores.

[0] https://notendur.hi.is/vae11/%C3%9Eekking/principles_of_math...