Is Spatial Ability the "Geek Gene"?(amazon.com)
amazon.com
Is Spatial Ability the "Geek Gene"?
http://www.amazon.com/gp/blog/post/PLNK2IF0DTPLYZ5ZS
34 comments
Interesting topic of conversation: Are there any good programmers here who would say that they do not think visually about their programs? If so, how do you think about them? I'm especially interested in the larger-scale; I don't know that I "visualize" a single function, but I can't understand the architecture without something like a visualization.
I can't answer this question. I'm definitely visual, but I'm intrigued at any alternatives anyone could try to explain.
I can't answer this question. I'm definitely visual, but I'm intrigued at any alternatives anyone could try to explain.
I think my approach could be described as a combination of intuitive and feeling (closely backed up by thinking). The visualization is more a tool used to serialize out thoughts for historical or communicative purposes.
I rely more on feelings rather than visualizations. For example I don't usually visualize the hierarchy of a program. I feel my way around it. I'll use my editor/debugger/REPL to jump me from place to place to build up a non-visual structure of the program in my head.
If I need to communicate the hierarchy a block diagram, UML diagram, ASCII art, English prose may be drawn but that's not what's in my head at all when I'm working.
More importantly I'm often feeling for inconsistencies and patterns. Most importantly I'm feeling for elegance and simplicity. If one thing seems a little bit different than a couple of other things I'll make it be the same. If a number of things feel the same I will abstract out the commonality. Visualization does not help me do those things at all. I need to load the program into my mind and then I just start noticing/feeling the essence/problems/cleverness/joyfulness/messiness etc.
I think you're right that when it comes to learning something quickly or communicating something a visualization helps greatly.
I rely more on feelings rather than visualizations. For example I don't usually visualize the hierarchy of a program. I feel my way around it. I'll use my editor/debugger/REPL to jump me from place to place to build up a non-visual structure of the program in my head.
If I need to communicate the hierarchy a block diagram, UML diagram, ASCII art, English prose may be drawn but that's not what's in my head at all when I'm working.
More importantly I'm often feeling for inconsistencies and patterns. Most importantly I'm feeling for elegance and simplicity. If one thing seems a little bit different than a couple of other things I'll make it be the same. If a number of things feel the same I will abstract out the commonality. Visualization does not help me do those things at all. I need to load the program into my mind and then I just start noticing/feeling the essence/problems/cleverness/joyfulness/messiness etc.
I think you're right that when it comes to learning something quickly or communicating something a visualization helps greatly.
I also think in this way; I typically describe it to technically inclined people as being kind of like thinking with a command line interface instead of a GUI, although the metaphor is rather imperfect.
More strangely (to most people with whom I have spoken), I often dream entirely without images--occasionally even as written prose.
Edit: Perhaps interestingly, this does not seem to harm my ability to do spatial inference, but I have essentially no long term image recall.
More strangely (to most people with whom I have spoken), I often dream entirely without images--occasionally even as written prose.
Edit: Perhaps interestingly, this does not seem to harm my ability to do spatial inference, but I have essentially no long term image recall.
+1 I think, though it's hard to tell from a written description whether you're describing the same mechanism I use to get around a codebase.
I usually think of my mental model of the code as being a map, yet it's not a visual, 2D map. It's more a collection of associations - I know that if I follow this function, it'll have this effect on the world, and this function is used from 4 other places, all of which need it to do this, etc. It doesn't really map well onto 2D visuals at all, because I suspect code has way more than two dimensions. But maybe like a massive graph lattice...
I use the same mental mechanism for getting around town, so it's definitely spatial, but not necessarily visual. I guess the best distinction I can draw is to compare looking at a map of a town, vs. actually living in the place. For example, I got lost today in a twisty residential cul-de-sac while hunting for an estate sale that never did materialize. But I knew I was in the corner between 101 and 85, and I knew I'd come from Middlefield, so in the course of driving around I managed to put together a mental map that got me out of there. (FWIW, I was here: http://maps.google.com/maps?f=q&source=s_q&hl=en&...).
I find that I can't stand visualizations of software - they always confuse me far more than just looking at the code does. I'm not sure why - maybe it's because it's a leaky abstraction, and there're always connections that are very necessary that aren't represented on the diagram.
I usually think of my mental model of the code as being a map, yet it's not a visual, 2D map. It's more a collection of associations - I know that if I follow this function, it'll have this effect on the world, and this function is used from 4 other places, all of which need it to do this, etc. It doesn't really map well onto 2D visuals at all, because I suspect code has way more than two dimensions. But maybe like a massive graph lattice...
I use the same mental mechanism for getting around town, so it's definitely spatial, but not necessarily visual. I guess the best distinction I can draw is to compare looking at a map of a town, vs. actually living in the place. For example, I got lost today in a twisty residential cul-de-sac while hunting for an estate sale that never did materialize. But I knew I was in the corner between 101 and 85, and I knew I'd come from Middlefield, so in the course of driving around I managed to put together a mental map that got me out of there. (FWIW, I was here: http://maps.google.com/maps?f=q&source=s_q&hl=en&...).
I find that I can't stand visualizations of software - they always confuse me far more than just looking at the code does. I'm not sure why - maybe it's because it's a leaky abstraction, and there're always connections that are very necessary that aren't represented on the diagram.
I think you could describe the structure as being a directed graph with labelled edges and stuff inside each node. You build it up by inspection, debugging, documentation (when it's around), experimentation. You know who calls x. You know what x does. You know what x touches. You know who else touches those things too. What does that one do? Hrm. gasp (literally). There's the race! :) "He fixes radios by thinking!"
But again the graph idea is a formalization. It's more fuzzy and messy in my head. The graph is not perfect and requires care and feeding to stay alive. And you don't actually see the whole thing at once. You can move around inside it but there is a focus. It's something your subconscious operates on as much as your conscious mind. And it's the subconscious that generates the intuitive flashes.
But again the graph idea is a formalization. It's more fuzzy and messy in my head. The graph is not perfect and requires care and feeding to stay alive. And you don't actually see the whole thing at once. You can move around inside it but there is a focus. It's something your subconscious operates on as much as your conscious mind. And it's the subconscious that generates the intuitive flashes.
> I feel my way around it. I'll use my editor/debugger/REPL to jump me from place to place to build up a non-visual structure of the program in my head.
This is interesting because I am a "visual" developer and have never really used a gdb-style debugger at all in nearly 10 years of professional dev experience.
I prefer isolating problematic code programmatically and refactoring my mental picture of the architecture/data structures until I can mentally visualize what's going wrong in my math/logic. This has given me grief with hairy pointer code where running something like 'printf' actually changes stuff in memory that you're trying to look at, but I really just don't understand how anyone can use a debugger to step through things one line at a time when that's essentially what I'm doing in my head when I look at code.
Then again I've never worked on anything as complex as, say, an OS kernel, so what do I know.
This is interesting because I am a "visual" developer and have never really used a gdb-style debugger at all in nearly 10 years of professional dev experience.
I prefer isolating problematic code programmatically and refactoring my mental picture of the architecture/data structures until I can mentally visualize what's going wrong in my math/logic. This has given me grief with hairy pointer code where running something like 'printf' actually changes stuff in memory that you're trying to look at, but I really just don't understand how anyone can use a debugger to step through things one line at a time when that's essentially what I'm doing in my head when I look at code.
Then again I've never worked on anything as complex as, say, an OS kernel, so what do I know.
I always start by looking at the code and trying to get an intuitive leap about the problem. But if it does not come the next step will often be to drop a breakpoint on the first line of the 7 or 8 functions involved run it and feel the flow. One of my specialties is embedded code in C/C++. Not even an OS necessarily. ISRs changing state behind your back, etc. Feeling the program run can be important. Seldom do you single-step. Often you drop breakpoints at the important points like the first line of a function or the first line of an iteration.
Depending on what you mean by "isolating ... programatically" it might be very similar to how I sometimes use unit-tests in general or the REPL when programming in a high-level language such as Lisp or Python.
The unit-test/REPL lets you play with functions on an individual level. Checking inputs and outputs. Slowly synthesizing more complex arrangements which approach the problematic arrangement actually found in the real code.
All of this is about augmenting your intuitive understanding of the code with real solid empirical data about the behavior of the program. If you can't explain a given bug your intuitive understanding is somehow wrong or lacking and often you'll see surprising behavior when you actually instrument the program. Those surprises lead you to the solution.
Depending on what you mean by "isolating ... programatically" it might be very similar to how I sometimes use unit-tests in general or the REPL when programming in a high-level language such as Lisp or Python.
The unit-test/REPL lets you play with functions on an individual level. Checking inputs and outputs. Slowly synthesizing more complex arrangements which approach the problematic arrangement actually found in the real code.
All of this is about augmenting your intuitive understanding of the code with real solid empirical data about the behavior of the program. If you can't explain a given bug your intuitive understanding is somehow wrong or lacking and often you'll see surprising behavior when you actually instrument the program. Those surprises lead you to the solution.
I had an advisor once tell me something similar. The classes that are core for a university should be utilized by engineers because we are taught to think one way if you learn another way there will always be a place where you may be able to apply that new way of thinking; be it psychology, philosophy, a minor in another unrelated discipline.
I would have to agree that if you don't get anything out of a class not related other than learning how to think for that class you gained something very useful.
I would have to agree that if you don't get anything out of a class not related other than learning how to think for that class you gained something very useful.
I personally know people who are totally incapable of anything spatial but are very good with logic and maths. I score rather highly in standardised spatial tests myself, but I rarely think visually about algorithms or data structures. I found that doing so keeps me thinking inside the box, literally.
Many abstract problems are high dimensional and items are linked by functional relationships that are very difficult to express visually. I've seen so many people cripple their understanding of problems by forcing them into diagrams that are just plain wrong in some important respect.
I believe spatial thinking works very well for some things but completely breaks down for others. Just a very simple example. It's pretty easy to visualise a set of three numbers: {2, 7, 4}. Just put them into boxes. But now try to visualise the set of all primes or the set of all sets that do not contain themselves.
Even for sets that are finite at a particular point in time, like the set of adults, thinking of them as items in a box is very misleading. What would have to be visualised is really the membership criterion. But that set still contains items at a particular point in time, so how do you visualise the relationship between the membership criterion and those items?
I know what happens at that point. Vague visual analogies that keep readers of popular science magazines happy but have very little utility for actually doing research start to creep in.
But dont' get me wrong. I know very well that visualising things can help to understand many things very well. Just not all things, and the problem is that people don't know where to stop trying.
Many abstract problems are high dimensional and items are linked by functional relationships that are very difficult to express visually. I've seen so many people cripple their understanding of problems by forcing them into diagrams that are just plain wrong in some important respect.
I believe spatial thinking works very well for some things but completely breaks down for others. Just a very simple example. It's pretty easy to visualise a set of three numbers: {2, 7, 4}. Just put them into boxes. But now try to visualise the set of all primes or the set of all sets that do not contain themselves.
Even for sets that are finite at a particular point in time, like the set of adults, thinking of them as items in a box is very misleading. What would have to be visualised is really the membership criterion. But that set still contains items at a particular point in time, so how do you visualise the relationship between the membership criterion and those items?
I know what happens at that point. Vague visual analogies that keep readers of popular science magazines happy but have very little utility for actually doing research start to creep in.
But dont' get me wrong. I know very well that visualising things can help to understand many things very well. Just not all things, and the problem is that people don't know where to stop trying.
I have some similar thoughts.
For example, when people learn about 2-space and 3-space (or 2-d and 3-d arrays), the most common thing to do is to draw out the spatial analogue: a WxH table, a WxHxD cube. And so the examples always stop at 3.
But in math you don't stop anywhere. I have wondered if people who have extreme finesse with math at arbitrary dimensions change strategies when dealing with higher dimensions, or if they never did this spatial conversion all along and deal with it completely symbolically.
Then I tried to think of what certain things mean symbolically. In integration it's always the area. But in symbols it's just a cold, unfriendly product. I'm sure there are merits to doing it this way, but I have trouble seeing intuitive meaning in it. Perhaps the better mathematicians simply calculate and don't care about what sense it makes?
For example, when people learn about 2-space and 3-space (or 2-d and 3-d arrays), the most common thing to do is to draw out the spatial analogue: a WxH table, a WxHxD cube. And so the examples always stop at 3.
But in math you don't stop anywhere. I have wondered if people who have extreme finesse with math at arbitrary dimensions change strategies when dealing with higher dimensions, or if they never did this spatial conversion all along and deal with it completely symbolically.
Then I tried to think of what certain things mean symbolically. In integration it's always the area. But in symbols it's just a cold, unfriendly product. I'm sure there are merits to doing it this way, but I have trouble seeing intuitive meaning in it. Perhaps the better mathematicians simply calculate and don't care about what sense it makes?
I'm not one of the better mathematicians so I cannot know, but I suspect you are right. And if you think of physicists, much of what they do is finding out what space is in the first place. So for them to rely on spatial metaphors or visualisations could be downright destructive to their thinking. And I believe the same holds for much of the logic we create in software.
I don't remember the exact words, but in his video lectures about linear algebra Gilbert Strang says he has no real visual concept of higher dimensions.
Alan Kay had a talk in which he claimed there were three ways of reasoning: kinesthetic, visual and symbolic. Presumably mapping the problem on to the various existing bits of hardware in the brain.
If this is true multiple lecture streams would seem best. I've never understood why all universities think they have to have their own lecturers and courses. Mostly the lecturer just cribs the notes from someone else's and completes the process by reading them aloud to a bored or empty room.
If this is true multiple lecture streams would seem best. I've never understood why all universities think they have to have their own lecturers and courses. Mostly the lecturer just cribs the notes from someone else's and completes the process by reading them aloud to a bored or empty room.
I went to an art school in brooklyn & learned 3d design as part of a formal spatial program. The big insight that was beat into us is to start by simply symbolizing an object - squint at it until the rest blurs away - and then gauge/adjust/repeat the relationships between the pieces you're left with. Persist until it's second nature and it'll be powerful magic for a designer in any field. Abstraction can be rather useful, in a conference room or a startup.
here's some background:
http://www.rowenafund.org/about/rrk_about_rowena.html
http://boxesandarrows.com/view/foundations-of
here's some background:
http://www.rowenafund.org/about/rrk_about_rowena.html
http://boxesandarrows.com/view/foundations-of
Anecdotal evidence inbound.
I know I am a very visual thinker. When given a box of parts I can visualize how they fit together in my head. I can take things apart and put them together different ways without actually touching them.
It took me a long time that not everyone thinks that way; and it was the source of a lot of frustration for me that people wouldn't get what I was saying.
I don't know if it makes visual thinking a geek gene, but it certainly does help in reasoning about problems. You can treat a lot of software as a set of mechanical problems versus abstract ideas. If you can flip a picture of something around in your head, it makes it easy to see if something will work or not; you know immediately if the parts won't fit.
I know I am a very visual thinker. When given a box of parts I can visualize how they fit together in my head. I can take things apart and put them together different ways without actually touching them.
It took me a long time that not everyone thinks that way; and it was the source of a lot of frustration for me that people wouldn't get what I was saying.
I don't know if it makes visual thinking a geek gene, but it certainly does help in reasoning about problems. You can treat a lot of software as a set of mechanical problems versus abstract ideas. If you can flip a picture of something around in your head, it makes it easy to see if something will work or not; you know immediately if the parts won't fit.
"You can treat a lot of software as a set of mechanical problems versus abstract ideas."
I disagree. There are a lot of things in software that have no counterpart in the physical world and that definitely obey no law of physics besides self-consistency, so I'd call them abstract and not mechanical.
Sometimes you'll be able to visualize some parts of the system as "mechanical" but if you stick to that representation you'll never be able to see the bigger picture.
I disagree. There are a lot of things in software that have no counterpart in the physical world and that definitely obey no law of physics besides self-consistency, so I'd call them abstract and not mechanical.
Sometimes you'll be able to visualize some parts of the system as "mechanical" but if you stick to that representation you'll never be able to see the bigger picture.
"a lot", not all.
Surprised no one has mentioned how men consistently outperform women at spacial ability tests. Perhaps that would explain why there are more male hackers. Or is that just too logical ;)
eg http://www.medicalnewstoday.com/articles/133575.php
eg http://www.medicalnewstoday.com/articles/133575.php
On the other hand, adding a few explicit lessons on mental 3d rotation at the start of some university's chemistry (organic? - I can't remember) significantly narrowed a male/female performance gap.
I'd be interested in what the content of that course he mentions (to strengthen spatial ability) is like. It'd be interesting to see if it helps even those who are gifted in the area.
It seems like spacial ability also gives one somewhat of an advantage on IQ tests, since these seem to be disproportionately focused on spacial transformation questions.
It seems like spacial ability also gives one somewhat of an advantage on IQ tests, since these seem to be disproportionately focused on spacial transformation questions.
I never understand things from textbooks or from other people. I have to work it out myself. (I've come top of my class at uni, so it works for me).
This is in line with the article's internalization point.
I'm also wary of reducing my understanding to code or even written notes before it is settled, because it is much more malleable in the mind. This is in line with the article's transformability.
Interesting point about gestures. My thinking is very kinesthetic, so I might try that.
I'm also wary of reducing my understanding to code or even written notes before it is settled, because it is much more malleable in the mind. This is in line with the article's transformability.
Interesting point about gestures. My thinking is very kinesthetic, so I might try that.
It's said that musicians make good programmers.
One point of similarity is that both can use their "shape brains" to solve problems.
For musicians other than pianists, a common way to memorize a piece is to pay it repeatedly, each time moving the music stand farther away. Distance obscures more and more details.
I've been able to find problems by printing out code and stepping back until I could just see the structure. Yes, this only works given consistent indentation.
One point of similarity is that both can use their "shape brains" to solve problems.
For musicians other than pianists, a common way to memorize a piece is to pay it repeatedly, each time moving the music stand farther away. Distance obscures more and more details.
I've been able to find problems by printing out code and stepping back until I could just see the structure. Yes, this only works given consistent indentation.
For musicians other than pianists, a common way to memorize a piece is to pay it repeatedly, each time moving the music stand farther away.
I once was an orchestral musician and I'm from a family of orchestral musicians, including one who is a pro, and I've never seen or heard of anyone doing this.
I once was an orchestral musician and I'm from a family of orchestral musicians, including one who is a pro, and I've never seen or heard of anyone doing this.
Years ago, I enjoyed reading books about how to do arithmetic mentally and quickly (there are several of them - one good one is "Math Magic" by Scott Flansburg). There did not seem to be anything equivalent for more abstract math, i.e. algebra and calculus. For some reason, I cared so much that I actually took the trouble to write a couple of books about it (http://hilomath.com/).
To figure out what to write, I actually sat down with an old algebra text book, and while solving the problems in my head, very carefully observed what I did and how... then wrote down how it all worked, using words and images. This process was about a hundred times harder than it sounds; had I any clue how hard it would have been, I probably never would have started.
Anyway, for doing abstract/symbolic math mentally, the method I came up with defines three levels of fundamental mental skills that are learned in succession, and build on each other:
What I called "representations" has to do how we encode information mentally. To give a programming example, how do you visualize a linked list data structure? Well, probably most of us (I'm assuming you're a hacker/math hat here) have a visual model in which there is some repeated symbol representing the nodes, and some aspect of the symbol that represents a pointer to another node, with these nodes arranged in a line (as opposed to a 2D grid, or random cluster, etc.). Perhaps you even visualize lines connecting the node-symbols (i.e. pointers to the next node). There are infinite possible variants, and maybe you do it differently. Importantly, your visual model will omit encoding much information that happens to not be immediately relevant (such as the endianness of the data stored, etc.)
Bringing it back to math, consider the equation (x+3)/(2x+4)=1. Let's assume you can solve that in your head. (If not, you need to read my book :) Maybe try it right now, and notice how you visualize the equation and its symbols, and how you move or manipulate the symbols as you solve it. An obvious first step is to bring the denominator on the left over to the right side. Mentally, you probably see this as the movement of the expression "2x+4" as a whole unit. You chunk it as a single object, then break it up into smaller objects later when that's needed.
The next level is what I'm calling mental algorithms, which I won't describe here - for most of the people reading this, it's just what it sounds like.
To figure out what to write, I actually sat down with an old algebra text book, and while solving the problems in my head, very carefully observed what I did and how... then wrote down how it all worked, using words and images. This process was about a hundred times harder than it sounds; had I any clue how hard it would have been, I probably never would have started.
Anyway, for doing abstract/symbolic math mentally, the method I came up with defines three levels of fundamental mental skills that are learned in succession, and build on each other:
* visualization
* representations
* mental algorithms
What I called "representations" has to do how we encode information mentally. To give a programming example, how do you visualize a linked list data structure? Well, probably most of us (I'm assuming you're a hacker/math hat here) have a visual model in which there is some repeated symbol representing the nodes, and some aspect of the symbol that represents a pointer to another node, with these nodes arranged in a line (as opposed to a 2D grid, or random cluster, etc.). Perhaps you even visualize lines connecting the node-symbols (i.e. pointers to the next node). There are infinite possible variants, and maybe you do it differently. Importantly, your visual model will omit encoding much information that happens to not be immediately relevant (such as the endianness of the data stored, etc.)
Bringing it back to math, consider the equation (x+3)/(2x+4)=1. Let's assume you can solve that in your head. (If not, you need to read my book :) Maybe try it right now, and notice how you visualize the equation and its symbols, and how you move or manipulate the symbols as you solve it. An obvious first step is to bring the denominator on the left over to the right side. Mentally, you probably see this as the movement of the expression "2x+4" as a whole unit. You chunk it as a single object, then break it up into smaller objects later when that's needed.
The next level is what I'm calling mental algorithms, which I won't describe here - for most of the people reading this, it's just what it sounds like.
> consider the equation (x+3)/(2x+4)=1
My first step was to replace the / with = and ignore the =1 since the numerator and denominator must be the same. I like to come up with ways that keep the main parts of a problem near each other, rather than separating them by bringing 2x+4 to the far right.
My first step was to replace the / with = and ignore the =1 since the numerator and denominator must be the same. I like to come up with ways that keep the main parts of a problem near each other, rather than separating them by bringing 2x+4 to the far right.
My mind's eye is blind. I find it basically impossible to mentally visualize things, except for when I'm dreaming. And even then, everything I see in my dreams is "blurry", and often times monochrome. I wish there was a way to acquire the ability to visualize.
You know, might be able to help. I've been developing a "how to gain the ability to visualize" program, and could use some beta testers. Message me or send email to amax @@@ hilomath.com if you're interested; it's going to be a for-sale product, but you can have it for free if you're willing to tell me what you think. (This goes not just for you, palish, but anyone else reading this in the next week or so.)
Interesting article, and one that brings to mind one of my pet peeves: when people say "I'm a visual learner" to use as excuse for not understanding a point or concept. They then usually need someone to literally draw it out for them.
My main problem with this is the fact that, as humans, we are all visual animals. We are not bats (aural), dogs (olfactory), snakes (tasters) or some creature that relies primarily on our sense of touch. We are humans and we are all visual learners - everything is easier to learn for everyone if it's drawn out.
What this article pointed out to me is that our individual abilities to visualize concepts differ. While some people need it drawn out for them, some are able to draw it out for themselves in their mind.
My main problem with this is the fact that, as humans, we are all visual animals. We are not bats (aural), dogs (olfactory), snakes (tasters) or some creature that relies primarily on our sense of touch. We are humans and we are all visual learners - everything is easier to learn for everyone if it's drawn out.
What this article pointed out to me is that our individual abilities to visualize concepts differ. While some people need it drawn out for them, some are able to draw it out for themselves in their mind.
"The fact that we in computing keep trying to visualize introductory computing concepts is another piece of evidence for me that spatial ability is linked to success with computing. We naturally try to use visualizations of algorithms and data structures in order to communicate how we imagine these computing processes and structures. However, there's some evidence that this is the wrong answer.
A visualization may not be designed so that it's cognitively easy to process or easy to learn from. Worse, providing the visualization may prevent the student from internalizing the spatial mental model. You can only succeed in computing (my hypothesis suggests) if you can mentally transform your spatial models. If it's concretely in front of you, you may not develop that ability. Some of the SILC results suggest (to me, at least) that gesture may be a better way to communicate the spatial model. Gesture is ephemeral, and still serves to communicate spatial meaning."
My take: in computing, "visualizing" how systems work actually requires thinking in N dimensions. If you try to represent something composed of a large number of dimensions in 2D or 3D, then of course you lose a lot of semantic context. But if you have to explain such an N-dimensional concept or structure to someone, of course you'll probably try to dump the model on a piece of 2D paper and the person you're explaining to will never really get it if he sticks to the 2D representation. "Internalizing" the model is simply reverse-engineering the 2D model back to the real N-dimensional model.
If you try to represent something N-dimensional in M dimensions where M < N, you lose information and your new model will never be able to represent the full reality of the original model.
A visualization may not be designed so that it's cognitively easy to process or easy to learn from. Worse, providing the visualization may prevent the student from internalizing the spatial mental model. You can only succeed in computing (my hypothesis suggests) if you can mentally transform your spatial models. If it's concretely in front of you, you may not develop that ability. Some of the SILC results suggest (to me, at least) that gesture may be a better way to communicate the spatial model. Gesture is ephemeral, and still serves to communicate spatial meaning."
My take: in computing, "visualizing" how systems work actually requires thinking in N dimensions. If you try to represent something composed of a large number of dimensions in 2D or 3D, then of course you lose a lot of semantic context. But if you have to explain such an N-dimensional concept or structure to someone, of course you'll probably try to dump the model on a piece of 2D paper and the person you're explaining to will never really get it if he sticks to the 2D representation. "Internalizing" the model is simply reverse-engineering the 2D model back to the real N-dimensional model.
If you try to represent something N-dimensional in M dimensions where M < N, you lose information and your new model will never be able to represent the full reality of the original model.
I am the counterexample. I have always been relatively poor at visualization and spatial manipulation. That said, I am not a spectacular programmer, and rely more on my ability to cut through to the real concerns of people than on my ability to create innovative technical solutions.
Can anyone recommend resources / activities to improve spatial visualization abilities? I would think this would help everyone become a better critical thinker. Thanks.
That is a rather interesting premise. More anecdotal evidence inbound!
When I undertook an IQ test a couple of years ago, I scored significantly higher in spatial ability to the majority of the other abilities tested. I'm also a self-taught programmer, and I do reasonably well, I'd like to think.
When I undertook an IQ test a couple of years ago, I scored significantly higher in spatial ability to the majority of the other abilities tested. I'm also a self-taught programmer, and I do reasonably well, I'd like to think.
non-linear data relationships seems to be the dividing line to me. being able to compartmentalize concepts in different ways and then play with the relationships between compartments.
"It sounds to me like spatial ability may predict success in CS1 because that is the way we TEACH CS1. If we taught it a different way, different students would succeed."
And perhaps if people with different kinds of minds moved into computer science, some problems that now appear intractable would appear easy to those people. Diversity of thinking styles appears to be good for a developing discipline.