That means you have a very clear outcome of what do you want from the code. You spend the minimal amount of energy in order to understand the forest before you look at the trees, and you only spend time on the trees that you need.
What I do is not reading, I execute parts of the code,and debug it, so I get the "feeling" of what the code does before I know exactly how it does it.
In something moves like a dog, barks like a dog, eats and moves the tail like a dog....odds are it is a dog. Humans identify things by global behavior much better that painfully studying a hair or something.
There is code out there that is not worth reading, as it is so complex. Take for example Tex, it was created to be so efficient in old machines, that is almost impossible to read without expending a tremendous amount of time. But understanding how it behaves is easy.
I use my own visual tools to inspect and debug the code visually in a high level way, for example instead of just a number I can "see" a point, that is 3 coordinates, or a polygon that is tree points and a normal vector. Without these tools I would be seeing individual numbers(or nodes in a tree)having to reconstruct the whole using my mind(not good).
Those visual tools are created in a fast prototyping environment(dear imgui) with debugging scripts in order to see more globally.