[erez]

First, broaden the concept of "entirety of the segment". For most it's the immediate scope, or maybe the next level. I'm referring to understanding every element in there, where it comes from, and what it affects, even if you need to look in several other modules for that.

But, the idea is to try and understand why was the code written like that, what is the model the original programmer had in mind, and whether there could be more of the same errors in other places. It's the way you can see a db table and immediately know where will there be issues in the db design.

[formula1]

Yeah, understanding how each peice works is generally a good idea since software tends to be very delicate. I certainly hope a programmer is willing to go deeper and deeper into 3rd party modules until they discover the root of the problem.

When you say it, it sounds complicated, nuanced and elegant. But, from personal experience, it simply relates to mental rules like "make sure your fix doesnt screw up more things" and "if you think a programmer is doing something weird, its probably weird" and "if everything looks fine here, look upstream"

For something like database design, usually there is a restriction of the orm that causes fluff or the programmer is trying to minimize memory usage by reusing variables or something else that can cause utter chaos. Im all for "thinking like the writer", but I feel like that doesnt present actionable steps only to approach it with sympathy. Id argue, get a mental model of minimal necessary steps and see how the other program fits into it or expands upon it.