I find this mirrors my experience. Although written language does eventually call upon highly visual parts of the mind, the structures and mechanisms I visualize when reading code are more highly dimensional than the initial mentally vocal interpretation of text. A program small enough to hold entirely in my mind that I know well, such as a piece of demo-scene code I'm golfing, is a sort of multifaceted non-visual abstract sculpture with features and values that interconnect in a seamless manner that I can interact with and predict the effect of my modifications on. I highly enjoy being utterly engulfed in the flow of this simultaneously logical and artistic activity.

That is how I have thought about code as well. I sort of grasp the "shape" of it, and the analogy to a board game is a good one. I think it supports why it is hard to talk about code, if we thought of it as speak-able units we could paraphrase it.

This is also why visual low-code programming might actually succeed: it's closer to how you think about code than the actual code. It has the opportunity to visualize the structures you want to see, so you don't have to make that translation yourself.

Visual low-code programming sounds good until you try to express actually non-trivial stuff in it, and you start appreciating text-based flow control again.

My take is that since code and data are highly dimensional "ideas" living in a one-dimensional address space, the two dimensions of visual programming that don't match any of the two are more of a distraction.

For visual low-code programming to align with how I visualize code, it would need to have one modality for when I'm writing, and a much richer, more complex modality for when I'm troubleshooting. There is a lot of emphasis in visual low-code programming on the first but not the second modality. There is a third modality for reading as well, which is very similar to troubleshooting but usually can be mostly a subset of troubleshooting.

YMMV, but the way I reason through while I read/write/troubleshoot code are mentally visualized and mapped in very different ways. When I compare what I visualize with the junior engineers I support, their visualizations tend to stop at a much higher granularity level. I strongly suspect that I engage in techniques that would be extremely familiar with and be on far more elementary level to those who practiced building "memory palaces" [1].

I have tried to teach this to the junior engineers, but the vast majority are simply wired differently it seems, and the few who "get it" do not sufficiently make it a habit to internalize it, much of which at first involves tedious pencil and paper.

I remember as a kid while blundering about a PDP-8 drawing on paper what I thought was going on at first with labeled boxes and lines (most of which was laughably inept and naive), then gradually transferring that to memory. Over many years of practicing that, it eventually became a reflexive habit. For more difficult problems I encounter today, I still sit down with pencil and paper and diagram it out to talk myself through it and build up a mental model.

For me personally, engaging spatial, motor, visual, verbal, and auditory senses together makes up my "visualization" in an iterative process that gradually internalizes into a pure mental model. That's why I prefer to look like a mental patient in the confines of my private office than at a co-working space or coffee shop.

[1] https://en.wikipedia.org/wiki/Method_of_loci

This is unsurprising given that abstract algebra/type theory/category theory are often viewed through the philosophical lens of Srtucturalism.

https://en.wikipedia.org/wiki/Structuralism_(philosophy_of_m...