> When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people o

> When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. I concur, that's a good way to put it. The "way of the programmer" requires an unnatural way of reasoning that takes a lot of effort to master, and requires a lot of short-term memory effort to mentally simulate how the code behaves. I don't even think this programming style is truly required for professional programmers either; more a by-product of how programming started as a way to feed instructions to mono-processors in the context of mathematics and physics computations on limited hardware. Symbolic business logic doesn't typically depend so strongly on the specifics of runtime execution, and recently there has been a very active movement to build new programming environments which emphasize the relationship between code and data, rather than between code and intermediate states of computation as in classical programming languages.