How is programming affected by spatial aptitude? [closed]

Question

Background

The longer I work on a project, the less clear it becomes. It's like I cannot seperate various classes/objects anymore in my head. Everything starts mixing up, and it's extremely hard to take it all apart again. I start putting functions in classes where they really don't belong, and make silly mistakes such as writing code that I later find was 100% obsolete; things are no longer clearly mappable in my head. It isn't until I take a step back for several hours (or days sometimes!) that I can actually see what's going on again, and be productive.

I usually try to fight through this, I am so passionate about coding that I wouldn't for the life of me know what else I could be doing. This is when stuff can get really weird, I get so up in my head that I sort of lose touch with reality (to some extent) in that various actions, such as pouring a glass of water, no longer happen on a concious level. It happens on auto pilot, during which pretty much all of my concious concentration (is that even a thing?) is devoted to borderline pointless problem solving (trying to seperate elements of code). It feels like a losing battle.

So I took an IQ test a while ago (Wechsler Adult Intelligence Scale I believe it was) and it turned out my Spatial Aptitude was quite low. I still got a decent total score, just above average, so I won't have to poke things with a stick for a living, but I am a little worried that this is such a handicap when writing/engineering computer programs that I won't ever be able to do it seriously or professionally.

Question

I am very much interested in what other people think of this...

Could a low spatial aptitude be the cause of the above described problems?

How is programming affected by spatial aptitude?

Maybe I should be looking more along the lines of ADD or something similar, because I did get diagnosed with ADD at the age of 17 (5 years ago) but the medicine I received didn't seem to affect me that much so I never took it all that serious.

As far as I know people are born with low/med/high spatial aptitude, so I think it's interesting to find out if the more fortunate are better programmers by birth right.

Answer 1

There's actually some hard research data on this, mostly collected over the past 35 years, and I also have experienced a few similar phenomenons, though not on a regular basis. See below for more.

Research Data

There appears to be some but minor correlation based on research performed and summarized in the following works. As often with research though, the study models differ between studies and they should be closely reviewed to understand why results present differences in conclusions.

• Exploring the psychological predictors of programming achievement [PDF] (Erdogan, Aydin, Kabaca, 2008)

  Unfortunately this one is vague on details. It points to the "high-impact" of "aptitudes" in general, but then only points to other research without giving the results for each aptitude test, so we don't know how spatial ability fares. It's mostly a litterature review more than actual research.

• Spatial ability and learning to program [PDF] (Jones, 2008)

  From the results of this analysis, there is evidence that spatial ability is important when learning to program. [...] While spatial ability has been shown to be relevant, we do not feel that mental rotation capacity should be used as a means of predetermining programming aptitude, but should be considered while devising pedagogical interventions. Thought needs to be given to teaching methods and software visualizations that help students with low spatial ability to envisage abstract concepts and build better mental models (Wiedenbeck et al., 2004).

• Predictors of Success in a First Programming Course [PDF] (Simon, Fincher & al., 2006)

  Only a small positive correlation was found between scores in the spatial visualisation (paper folding) task and programming marks. This suggests that components of IQ other than spatial skills may account for most of the effect of IQ on programming success (Mayer et al 1989).

• Who is likely to acquire programming skills? (Shute, 1991)

• Hemispheric Lateralization and Programming Ability, (Gasen, Morecroft, 1990)

• Correlates of problem-solving in programming [PDF] (Choi-man, 1988)

  Interesting one... Nice study model, and quantified results with several study groups and accounting for the reliability of study factors. It yields that:

  [...] it could be seen that, for the males, mathematics alone could account for 30.90% of variance on programming ability, and that spatial test could account for 8.00%. [...]

  [...] it could also be seen that, for females, only the performance of mathematics and spatial tests had significant effect in predicting the programming ability.

  Results of this study revealed that students who scored high in mathematics test and spatial test would score high in programming ability test.

• Learning, research, and the graphical representation of programming (Taylor, Cunniff, Uchiyama, 1986)

• Cognitive Requirements of Learning Computer Programming in Group and Individual Settings (Webb, 1985)

• Cognitive correlates of programming tasks in novice programmers (Irons, 1982)

• Research on aptitude for learning: A progress report [PDF] (RE Snow, 1976)

Take it with a pinch of salt: Some are relatively dated, IQ tests might have changed since. I haven't done an in-depth search to find citations of each article to see if they were confirmed or debunked later on.

Some links (especially the [PDF] kind) may not work for you if you don't have an affiliation to a library giving access to these online contents.

---

Personal Opinion

Warning and disclosure: I am NEITHER a psychologist NOR a neurologist, but I have been studying and teaching programming to both small kids (starting 6) and university students (up to 60!).

Having studied with AND taught students as university teacher myself, including some students affected by spatial problems (and others with stronger disabilities), I have to say that while it could have been (I didn't keep track of my students based on disabilities, obviously) that some would have registered in a lower part of the general curve, I still remember clearly some scoring high (and even one in particular being the class' major for at least 2 years).

My point is, while it may have an effect, and as shown by some of the research above, it doesn't account for the largest part of your ability to learn to program and think like a programmer. It's inconsequential, in that it won't stop you to learn if you really want to, and won't prevent you from working in the general case, though it could (as might be your case) make it slightly harder for you.

There's virtually no limit to what and how fast you can learn.

After all, no programmer doesn't like a good challenge, right? (I'm looking at you, RSI)

---

Personal (Possibly Unrelated) Experience

It might be that you are too passionate. How many hours do you work per day and per week? Do you take regular breaks?

A Similar Case?

At a period in my life, I worked days of at least 14 hours every day of the week, the whole year, to a point where it culminated to record weeks of 120 hours of work in front of a computer screen. Yes, that's only 48 hours left per week to eat, sleep, travel to and from work (tip: avoid driving!!), shower and other vital functions. At this particular point, I could pretty much go to sleep in a heart-beat (though usually having sleeping problems), but I would almost always keep dreaming of code, and I would also suddenly realize in the shower or even when walking or running or doing menial tasks that my mind went back to it in auto-pilot, as you said it yourself. Unfortunately, I wouldn't magically solve problems in my sleep; it would be closer to what you seem to describe and experience: a giant maelstrom of confused thoughts turning around in my head, which would sort of (seem to) make sense on a grander scale, but not clearly express any solution and without much success in grabbing one of these thoughts to focus on it, dissect it clearly and turn it into something useful. And this was usually rather tiresome and distressing.

Relaxation Might Help

Maybe you need to calm down just a bit, and relax and work less. Try to find something to take your mind off. Back then, I ended up often renouncing some precious hours of sleeping time to instead do something that would really stop this mad train of thought. It seems counterproductive, but I actually preferred to do a few thing where I would really relax than to sleep more and not be rested. The distraction for the nervous batteries, and the sleep for the physical batteries, in a sense.

Identifying Triggers

If that's not your case, then maybe there's something else involved in triggering this state for you. Try to isolate elements that are present in these situations, and see if you can reproduce this condition in other environments, to see if you find these elements as well. Does it happen more at work or at home, etc...

Isolation

Also, you may already have heard and tried this, but I have a friend with a minor spatial disability, and usually it helps for him, if working on computers, to be a in darker room, to avoid having too many complex views and windows open (to avoid distraction), and in general to keep things rather minimalistic (both in terms of design and colors, and in terms of content and representation).

Try also to take regular breaks, and to let your mind run free for short periods of time every 1 or 2 hours, based on what works best for you. Maybe adopt the Pomodoro technique or something similar (I don't have research on a correlation with this, but it could be helpful in forcing you to take breaks).

Answer 2

Ech... this deserves more than a comment.

"I usually try to fight through this"

Stop fighting. You're getting things twisted and making mistakes right? You may well have some unique issues but the manner in which your brain is rebelling is normal for anybody that's spent too long hyper-focused on a problem. When I was younger, way too much of my day was spent thinking at that highly conscious level and I wasn't doing myself any favors. Your problem isn't that you're not trying hard enough it's that you don't know when to quit.

I finally learned to appreciate the value of putting things on the back burner when I figured out that the only way to get to sleep at a reasonable hour was to will myself to think about absolutely nothing and was shocked to discover that within 10 minutes or so I'd fall asleep whereas normally I'd be thinking-thinking-thinking for at least a couple hours before crashing from mental exhaustion.

From there I found it easier to learn to recognize when I was putting way too much conscious thought into a problem and to just let it go for a while. I was surprised to discover how much this actually contributes to helping you work out a problem.

I recommend the following:

• When something is getting twisted in your head and you don't have the luxury of being able to take break and go for a walk or something, try to switch gears and focus on a very different piece of the problem for a while.

• Never skip lunch and always leave the office. Give yourself until you get to the door to come to a stopping point or just drop it. Anything worth keeping in your head will be there when you come back to it and all the stuff you didn't need will be gone. The more you discover this, the easier it gets.

• Regularly will yourself to think about nothing throughout the day. Even if it's just for a minute while you get yourself that glass of water.

• Try to leverage OOP or any more problem-domain-centric architectural approach to think about less. Who are the actors in your code at the highest level? They shouldn't have complex relationships with each other. That allows you to focus more on one piece of the problem at a time.

Some Coding Principles That Might Help

• DRY is to general coding practice as "Stealing is wrong" can be applied to almost all ethics/morality. There are very rare exceptions. Keep them very rare.

• If you're in the habit of over-solving for problems you might face eventually in the future, knock it off. Nothing is more future-proof or "scalable" than code that is no more complex than it needs to be. "Enterprise" is lies.

• Complex patterns often promise long bullet point lists of rewards. There are only 3 things that should matter most of the time. It's easy to read. It's easy to re-use. It's easy to modify. Think in terms of minimum use of force that a martial artist might and apply that principle to complexity. Exactly enough to solve the problem is ideal.

• Write your interface first. And no I don't mean the C#/Java constructs which should be used only when needed, I mean the API of your objects. What does the class/object need to do? Write those empty methods and give them arg names. Don't fill in the blanks until you're completely done. It's okay to make tweaks later but once you've established what it needs to be able to do, you can focus on how each thing, one at a time, needs to be done. The reason you may find yourself trying to hold as much in your head as you often do may be because you've got implementation happening for problems that should have been solved long before you got to a given stage of a process. Got lots of is and has methods? That's what I'm talking about. The thing that knew what it was or had should have solved the problem before it got to where you're invoking those methods.

Diagnosis?

I think the spatial awareness concern has been well-covered. Whatever you decide on that front, I'd give the ADD thing a revisit, especially if you were reluctant about it the first time. This definitely sounds a lot like hyper-focus gone to an extreme. Ultimately, let that love of coding drive you to find ways to mitigate these issues and I expect your career will turn out just fine.

Answer 3

How many hours do you work for before starting to see this blurring? Many average to good programmers I know of work 4, may be 5 hours before taking a coffee or lunch or something. The longest of such sprints I have read of is when Guy L Steele and Richard M Stallman did a 10 or so hour sprint when writing Emacs. Steele goes on to say that he would not want to do such a long sprint again.

If you are fairly new to (less than, say, 5000 hours (that number came from Peter Norvig's post on learning to program in ten years, by halving the 10000 hours that he recommends to become an expert programmer)) programming, this sounds very normal except for the part where you say you need days of break. Perhaps you are burning out yourself to make yourself need such a long break?

Answer 4

From what you describe, your problem may have various causes :

• Inexperience

• Loss of focus / fatigue

• Low spatial abilities

Inexperience can be solved by... well, gaining more experience, basically. However obvious it may sound, by practising more you'll find yourself in complex programming situations more often and will progressively learn to handle them. Right now you may lack the mental schemas and reflexes to make the right connections, draw the right conclusions and unlock these situations, which can make you feel like you're slow and write "obsolete code", but these problem-solving patterns will progressively take place in your head as you get more experienced (you're only 22 as I understand, which is still very young).

There are various techniques to improve your focus. Pomodoro and Getting Things Done are two examples. In the programming field, Test Driven Development is also something I'd really recommend since it forces you to concentrate on one small, achievable goal at a time (baby steps). With a TDD approach you're much less likely to "put functions in classes where they really don't belong" since you're forced to clearly define a responsibility of your class with a test and then focus solely on implementing it when you code, as opposed to jumping between several classes and filling them randomly little by little.

Fatigue and attention drops can be avoided by adopting a sustainable rythm with frequent breaks. You might find interest in that presentation by Linda Rising on being more productive by respecting our brain : Born to Cycle.

As for low spatial abilities, I'm afraid there's not a lot you can do about it. However, hard work can attenuate it and it's far from the being only skill required in programming. Things like creativity, passion, enthusiasm, rigor, analytic skills, sharpness, good grasp of business issues, collaboration skills, can more than make up for a weaker than average mental visualization of the code base.

In short, what you need IMO is :

• Discipline

• Practice

• A sustainable pace