I never hit a wall with mathematics. My approach was to write down what I have to and do everything else in my head.
I hit a wall within the first five minutes of programming. I know I will mistakes and I make up for that by making small, clear code commits and trying to make my code easy to read.
I'm a much better programmer than I am a physicist. I am also much happier working as a programmer than I was studying physics.
I definitely make mistakes, so one tactic I use is liberal use of code comments. I start with a comment about what the overall task is about, so that I can keep perspective, and then I will use a series of "TODO ..." comments to break things down into smaller steps.
The nice thing about this is, some of those survive revisions and can then be line comments which explain the next few lines of code:
# Frob the Foo.womble, so that Bar gets its input
# in the format it expects
Similarly, I have grown to use commit messages longer than one line, even if I expect to later rebase it together with something else.
I tend to design stuff on paper with logical boxes and arrows, then add that as a large comment at the beginning of a complex section, then implement it without any comments in the code. That way, the code is still readable but there is a reference above it. Just like you have in books on programming languages.
I hit a wall within the first five minutes of programming. I know I will mistakes and I make up for that by making small, clear code commits and trying to make my code easy to read.
I'm a much better programmer than I am a physicist. I am also much happier working as a programmer than I was studying physics.