As a terrible programmer my trick is to read statements backwards. Maybe programming should be taught that way too not just reading of it but the history of it all the way back to Charles Babbage, Ada Lovelace and even weaving looms.
I ran across an interesting essay on Medium recently on this topic, advocating a new approach to roadmaps focused on the problems: the problem roadmap. Instead of saying what new features the team will be working on in the future, map out what problems they’ll be working on.
I think that personally I do a lot of back-and-forth in-between forward and backward reading to construct the program logic in my working memory.
Edit: maybe, could you describe what you mean by reading backward? I read it originally as “reading from the first expression to be evaluated to the last one”, but I see now that you are talking about statements. If that’s the case I see a lot of issues related to the context/scope of a statement. Do you read, let’s say, from the last statement before closing a function, then up?
float_num = float(input("Enter float num: "))
The way I read it is: I need to enter a number, the number is input, it's a float, that number will be assigned to the variable float_num.
It's not the best example but for me at certain times it's far clearer. Most times it seems like I am reading the equivalent of a person writing backwards then it dawned on me to read it backwards.
Reading code forwards overwhelms your working memory because lots of information is at the beginning (e.g. class members).
If you read it backwards, you directly dive into the logic, while variable names give away what they're supposed to hold. As you progress further, you get a clearer view, and finally see how these variables are defined.