I think you're setting yourself up for disappointment with unrealistic expectations.
People that are in demand are programmers and good programmers code 90% of time. Some people, including yourself, suggested graphics but read the history of DOOM and read its source code: despite being a cutting edge technology at the time, 90% of the code is the non-math drudgery: reading and writing files, networking code, performant array and string classes, making the code cross-platform and cross-compiler, debugging code etc. Carmack certainly knows his math but he knows his C even more.
Math might be helpful/necessary in some fields but if you're thinking about being a programmer (as opposed to academic/researcher), don't expect math to be more than 10% of your time. The rest is the same drudgery that the rest of us has to deal with on a daily basis.
A math degree in a job where the outcome is software is like a chemistry degree in Antony Bourdain's archetypical restaurant kitchen: amongst the sharp knives and hot tempers, you will be able to deduce and induce properly, but the food has to be served.
But a math degree can give you confidence so that, when confronted with formal stuff you don't know, you know that you can know with a bit of effort. This is useful, for example, when reasoning with properties of algorithms. This is not useful, for example, when arguing about object-oriented design patterns which are not formally defined.
So you will do well with the aspects of Machine Learning (as many others suggested) which can be formally studied; whereas the hand waving artsy pantsy experimental part will feel like cooking with Bourdain.
This is an excellent point, although I disagree with 90%. Lots of a developer's time goes into QA/testing, design, and conversations about requirements and goals. I think developers spend much less than 90% of their time with an IDE open.
Comments
I think you're setting yourself up for disappointment with unrealistic expectations.
People that are in demand are programmers and good programmers code 90% of time. Some people, including yourself, suggested graphics but read the history of DOOM and read its source code: despite being a cutting edge technology at the time, 90% of the code is the non-math drudgery: reading and writing files, networking code, performant array and string classes, making the code cross-platform and cross-compiler, debugging code etc. Carmack certainly knows his math but he knows his C even more.
Math might be helpful/necessary in some fields but if you're thinking about being a programmer (as opposed to academic/researcher), don't expect math to be more than 10% of your time. The rest is the same drudgery that the rest of us has to deal with on a daily basis.
Agreed, and here's the cooking metaphor.
A math degree in a job where the outcome is software is like a chemistry degree in Antony Bourdain's archetypical restaurant kitchen: amongst the sharp knives and hot tempers, you will be able to deduce and induce properly, but the food has to be served.
But a math degree can give you confidence so that, when confronted with formal stuff you don't know, you know that you can know with a bit of effort. This is useful, for example, when reasoning with properties of algorithms. This is not useful, for example, when arguing about object-oriented design patterns which are not formally defined.
So you will do well with the aspects of Machine Learning (as many others suggested) which can be formally studied; whereas the hand waving artsy pantsy experimental part will feel like cooking with Bourdain.
This is an excellent point, although I disagree with 90%. Lots of a developer's time goes into QA/testing, design, and conversations about requirements and goals. I think developers spend much less than 90% of their time with an IDE open.
Some do and some don't. It obviously depends on what you're doing.