[coldtea]

>Code is not always the same as the process or what the machine actually does...

You started with why aren't they "just looking at the full flowchart [to understand the entirety]".

And the parent wrote that because the flowchart is not the entirety, the code is.

Do you think this retort you make above is refuting the parent's point? If anything, it expands it, going further against your original point: that's why they're not just looking at the full flowchart.

And, yes, "code is an abstraction, just like the flowchart", but code is the abstraction the programmer controls and tries to summarize and understand. The flowchart is a higher level abstraction of an abstraction.

[MichaelZuo]

Are you confused about the meaning of understanding vs a literal equivalence?

e.g. “ Because the code is the entirety of the process” is clearly false regardless of which way you look at it.

But ‘the code is the combined understanding of the entirety of the process’ may or may not be true depending on many many factors.

‘Understanding X’ clearly does not mean, or even imply, that it literally is this or that…

[coldtea]

>Are you confused about the meaning of understanding vs a literal equivalence?

No, but you seem to be about any context not spelled out completely and pedantically.

>e.g. “ Because the code is the entirety of the process” is clearly false regardless of which way you look at it.

A coder works on code (literally editing lines of code, which is what they deliver), and is called to create, understand, and debug code.

Else, sure, code also runs on some server, by some organization, that had meetings to decide the requirements, and there are also end users, and the whole thing runs in some planet, inside a universe, or perhaps a multi-verse, so the code its not the entirety of the process /s