I also became a software developer after getting a PhD in mathematics and specializing in three-dimensional topology.
One of the things I'm always struck by is how similar the process of writing code is to writing a math paper. There are similar issues of encapsulation and organization. Choosing the right abstractions and good names for things are both important. Definitions correspond to data structures; lemmas correspond to helper functions; theorems to higher-level functions; and sections to modules. You can also "refactor" a math paper in the same way you refactor code (e.g. renaming variables, choosing better names, etc).
What I've found missing in software relative to math is the creative / research part of math, since the math that comes up in software tends to be routine, easy stuff.
I am getting a PhD in mathematics after having programmed since I was 10, basically PhD level CS degree equivalent.
I see Mathematics as somewhat like programming but not exactly like you.
Bijections seem to show information equivalence, like two programs outputting the same information but in different encodings.
Mathematical structures like rings, groups, vector spaces, ideals, etc.. are like object classes, if you can cast your current structure to them -- or prove it is that kind of structure via duck typing or whatnot, you then get a whole slew of new methods, transformations, properties, and casts that you can use on the structure to further manipulate it.
Instead of learning APIs, we learn mathematical objects/structures and their properties (necessary to cast other structures or construct them.)
The casting is really key. Once you cast a bunch of disparate things around using their derives properties and you get an equality, you've got a bijection. Connect the islands. Boom, modular form <-> elliptic curve, etc. Langlands program!
I think programming first helped a lot with having the mindset for information equivalence. That's really the key to so many theorems. Things that appear different and cannot be compared until their representations converge through a lot of wormy structure alchemy. Then you either have equivalence or at least, like structures, so a comparison can be made, and thus a decent theorem.
I really want to study representation theory. I hardly know it but it seems to be a computational/information theoretic subset of mathematics.
> One of the things I'm always struck by is how similar the process of writing code is to writing a math paper.
Except when coding you never have to write down any proofs :)
> the math that comes up in software tends to be routine, easy stuff.
Software is easy until it grows big.
Math is often elegant because the problem can usually be stated in a concise way. In contrast, software usually has an ever growing list of requirements. It is balancing those requirements that makes software difficult.
Out of interest, how close are formal methods to the mathematical standard for proofs? VDM-SL was part of my degree, but the lecturer ended up showing more limitations than strengths by getting his own example wrong, and sadly I've had no real-life experience with them because none of my career to date has involved things that need to be proven correct.
One of the things I'm always struck by is how similar the process of writing code is to writing a math paper. There are similar issues of encapsulation and organization. Choosing the right abstractions and good names for things are both important. Definitions correspond to data structures; lemmas correspond to helper functions; theorems to higher-level functions; and sections to modules. You can also "refactor" a math paper in the same way you refactor code (e.g. renaming variables, choosing better names, etc).
What I've found missing in software relative to math is the creative / research part of math, since the math that comes up in software tends to be routine, easy stuff.