I struggled with this originally and it took years for it to click. But when it did I became both a much better programmer and mathematician for it.
I think what helps is to take the time to sit down and practice going back and forth. Remember, math and code are interchangeable. All the computer can do is math. Take some code and translate it to math, take some math and translate it to code. There's easy things to see like how variables are variables, but do you always see what the loops represent? Sums and products are easy, but there's also permutations and sometimes they're there due to lack of an operator. Like how loops can be matrix multiplication, dot products, or even integration.
I highly suggest working with a language like C or Fortran to begin with and code that's more obviously math. But then move into things that aren't so obvious. Databases are a great example. When you get somewhat comfortable try code that isn't obviously math.
The reason I wouldn't suggest a language like Python is because it abstracts too much. While it's my primary language now it's harder to make that translation because you have to understand what's happening underneath or be working with a diffident mathematical system and in my experience not many engineers (or many outside math majors) are familiar with abstract algebra and beyond so these formulations are more challenging at first.
For motivation, the benefits are that you can switch modes for when a problem is easier to solve in a different context. It happens much more than you'd think. So you end up speaking like Spanglish, or some other mixture of languages. I also find it beneficial that I can formulate ideas when out and about without a computer to type code. I also find that my code can often be cleaner and more flexible as it's clearer to me what I'm doing. So it helps a lot with debugging too
Side note: with computers don't forget about statistics and things like Monte Carlo integration. We have GPUs these days and that massive parallelism can often make slower algorithms faster :). When looking at lots of computational code it's not written for the modern massively parallel environment we have today. Just some food for thought. You might find some fun solutions but also be careful of rabbit holes lol
I think what helps is to take the time to sit down and practice going back and forth. Remember, math and code are interchangeable. All the computer can do is math. Take some code and translate it to math, take some math and translate it to code. There's easy things to see like how variables are variables, but do you always see what the loops represent? Sums and products are easy, but there's also permutations and sometimes they're there due to lack of an operator. Like how loops can be matrix multiplication, dot products, or even integration.
I highly suggest working with a language like C or Fortran to begin with and code that's more obviously math. But then move into things that aren't so obvious. Databases are a great example. When you get somewhat comfortable try code that isn't obviously math.
The reason I wouldn't suggest a language like Python is because it abstracts too much. While it's my primary language now it's harder to make that translation because you have to understand what's happening underneath or be working with a diffident mathematical system and in my experience not many engineers (or many outside math majors) are familiar with abstract algebra and beyond so these formulations are more challenging at first.
For motivation, the benefits are that you can switch modes for when a problem is easier to solve in a different context. It happens much more than you'd think. So you end up speaking like Spanglish, or some other mixture of languages. I also find it beneficial that I can formulate ideas when out and about without a computer to type code. I also find that my code can often be cleaner and more flexible as it's clearer to me what I'm doing. So it helps a lot with debugging too
Side note: with computers don't forget about statistics and things like Monte Carlo integration. We have GPUs these days and that massive parallelism can often make slower algorithms faster :). When looking at lots of computational code it's not written for the modern massively parallel environment we have today. Just some food for thought. You might find some fun solutions but also be careful of rabbit holes lol