Fluid intelligence (logical thinking, analytical thinking, pattern recognition, etc.; a factor of general intelligence) has been consistently proven to remain relatively stable throughout adult life, so improving it through practice would be—I'm afraid—sisyphean.
I note that you leave
critical thinking from your definition. Has critical thinking ability been shown to be static over ones' life? I rather suspect not, given that my own personal experience is that I have become more and more logical and a better critical thinker as I've aged.
If programming skill is to be entirely an acquirable skill that can be improved through training, then it must be distinct from fluid intelligence.
Not necessarily. Part of programming skill is learning to
apply your intelligence. Pattern recognition skills are not useful if the patterns that are recognized are irrelevant. Analytical skills are useless if you apply them only to minutae when big picture thinking is needed or vice versa. Solving a problem becomes painfully slow if you don't have experience to your inform fluid intelligence, as without experience, solving the problem necessitates inventing (which I note you're not accounting for at all in your posts) something that has already been invented, probably badly. Design patterns books and the like are an attempt to solve that problem somewhat. I'm a little disenchanted of "design patterns" of late, however. From what I've seen of Comp. Sci. majors who study them, they tend to encourage rote memorization and "thinking of the problem in terms of the solution" as opposed to actual programming.
If you want an anecdote: I started learning to program from books at age 9, but my ability didn't really improve beyond copy-pasting blobs of syntax around until I pushed myself into having to solve problems that didn't have neat solutions in the back of the books. It therefore seems obvious to me not only that a huge part of programming is the mindset one brings to the problem solving programming entails, but also that this mindset can be learned and unlearned.
If programming skill is to be entirely an acquirable skill that can be improved through training, then it must be distinct from fluid intelligence.
Programming performance then depends on programming skill and fluid intelligence.
If I heard someone talking about a programmer's "performance," that would imply to me a past tense - what a programmer was able to build and how quickly. What you're calling "programming performance" is what everyone I know would call "programming skill/ability." Many people believe that programming ability is something one is born with and that experience only makes you better at it.
A key part of "programming skill" that you've left out is the ability to turn theory into practice and how that is approached. That is vitally important. More than typing, I'd say. See my point above on "mindset."
If we thus factor out fluid intelligence,
If. I am unconvinced that factoring it out results in a useful distinction.
(1) knowledge of theory (i.e., understanding how different factors work together in different situations etc., this includes understanding gained from experience)
So you concede the point?
I believe if you re-read my posts with this understanding, and understanding of the terminology I use, you will understand my position.
Redefining words away from their commonly-accepted usage in order to fit them to your model of the situation has indeed made your position more clear. I will point out that no programmer I know would call the ability to type a part of a programmer's skill (except you, apparently - have you never taken a paper exam where you programmed?) and syntax is tangential at best to what I, at least, mean when I refer to "programming." We don't measure the skill of a programmer by their typing speed, we measure it by what they actually accomplish and how.
My conclusion was not just “jumped” to, but directly drawn from Kolb's theory.
Which is not without criticism, I note. The point that "empirical support for the model is weak" seems particularly damning.
This person would likely be far more motivated to learn by reading a book, and perhaps even give up when forced to learn too much by doing. But once sufficient knowledge and understanding has been acquired, the person might be keen to get to work, and perform very well; whereas when attempting to learn by doing during that time despite feeling discomfort, the person might perform significantly worse after the same amount of time.
Again, we're talking about different things. You seem to be talking about the process of learning individual things; we're talking about the big picture of learning to be a skillful programmer. At some point, one must leave the books behind to forge one's own path through the quagmire of others' bug-riddled, nigh-unreadable code (until you've learned to work with it) and poor documentation, and
actually write some code oneself to become a good programmer. That is the point being made. Apologies if that point was not quite clear.
I believe that there are some aspects of programming that one can only master by doing. Being one who learns faster by reading is irrelevant if there's nothing to read. I say this as one who does prefer to learn new things about programming from books, myself.