I believe that this tendency to generalization is why I am able to jump between levels of abstraction quite easily. The concept of emergence, and the specific cases of recursion and polymorphism, are obvious to me. Everything in the universe is made up of component parts, interacting in ways that give rise to the meta-phenomenon we observe, like “matter” and “consciousness”, and I can keep that in mind without worrying particularly about what those components are. It is odd to me when people consider things to be discrete, isolated wholes; it can be useful to talk about them that way, but I usually don’t actually believe it.
Programming at any scale beyond scripting involves building systems of components that interact to produce the desired outcome, so this conceptualization is handy. Even more applicably, debugging issues is the skill of diving into only those component parts that might possibly be causing the observed undesirable behavior. I’ll see a problem and know that somewhere there is an errant IF-statement, and can accurately guess the path or two it might be down. (The exceptions are when people break my assumptions, like yesterday’s bug caused by an untyped, string-identified property in the global context, but since people shouldn’t do those things anyway it’s usually not a problem.)
So what are the problems?
My dyslexia means that the most important thing for me about a language is the tool support, which often rules out new, hip languages. It took me a while to figure out that my dyslexia was the reason I and the command-line centric programmers would never agree. I've face prejudice against non-text-editor programmers, but often only until the first time they watch me debug something in my head. We all have our strengths ;-)
IDEs mean I don’t have to worry about misspellings or obvious syntactic errors and syntax-highlighting is invaluable. It’s even better when books use it too: the easiest textbooks for me to read were the computer science books with syntax-highlighting. Unfortunately, this was not most of them. Code can also often be represented visually: I highly recommend the HeadFirst series in particular [2]. This means that learning independently from books isn’t based on the ability to parse large blocks of prose [3], like it is in many other fields. For obvious reasons, I strongly prefer the object-oriented paradigm for large programs, though I've also gotten into aspect-oriented JavaScript, supported by Chrome's developer tools.
On the other hand, because I could never take communication for granted I believe I have become better at code switching and figuring out why I am failing to communicate. When feedback is available, I can debug conversations by spotting mis-matched assumptions or misunderstood statements and correcting them. This works less well in writing, obviously [4]. I have also found that programming talks lend themselves exceptionally well to visual communicators. I enjoy crafting a talk that grows a concept and bringing an audience along through the story. This has led me to interesting conferences, where I can refine my ideas and meet all sorts of people. Software development is an exceptionally social discipline and programmers have more resources to gather together and share our craft.
And the advantages?
Obviously, it is entirely possible to be a good programmer and be dyslexic. I would go further, though: I believe that in some ways dyslexia makes me a better programmer.The greatest strength of the dyslexic programmer is that if it is possible for syntax to be confusing, I will almost certainly confuse it. This is useful because so would almost everyone else, eventually. Most people have used > when they meant < at least once. Language constructs like meaningful whitespace or a lack of parentheses to delineate scope have caused major bugs, including the recent SSL vulnerability in OSX; they also make it almost impossible for me to comprehend code. I can never ever rely on numbers (they all mostly look the same), so I use readable constants instead. When I write Java Comparators, for example, I’ll have them return FIRST_GREATER, BOTH_EQUAL or SECOND_GREATER. Ordering is nearly useless and flag arguments incomprehensible. If I call the method twice it’s likely going to be faster to create a new object than do the extra work to ensure two arguments of the same type aren't flipped.
It's really about incentives: I’m less likely to tolerate ambiguities because I will mess them up constantly, instead of once in a blue moon when it may really matter and is less likely to be caught. I support coding styles, static analysis and languages choices that don’t allow anyone to make careless mistakes, reducing overall bugs [5]. They may catch errors in some near-perfect programmer’s code once every 100,000 lines instead of once every 1,000, but those are still bugs that have been prevented and were completely unnecessary.
I am also forced to design. I don’t get to write 500 line methods, because I get lost the first time a method swaps abstraction levels. I think secretly many people do: they just have a higher tolerance, whereas I’ll get knocked off-task and forget what I was trying to do in the first place until I extract a method or object. In order to write the fast, hacky approach I will often get halfway to a well-designed solution just in figuring out the problem: I may then go with the hacky quick-fix, but I’ll also remember how the code should look the next time I come back.
What has programming done for me?
Programming has been great for me, and would have been useful even if I didn’t pursue a career in software development.
Thanks to our tools, programming is a training ground with instant feedback. The easiest example isn’t programming-specific: spellcheck taught me to spell. First, it means as I write I don’t worry about whether I’m spelling something creatively. I can always fix it later, which keeps my cognitive load down and lets me focus on getting things done. Second, when I misspell a word it is immediately underlined in red. Over time I’ve even learned the pattern of keystrokes that keep the little red squiggle from appearing, much the same way I know Kilik's leg sweep in Soul Caliber. Now I can type many words correctly most of the time, without even once having to think about letters at all.
Similar dynamics work with programming languages in a good IDE. I am told instantly if I left off a semicolon or mismatched brackets or misspelled a function name. All I need to have at my fingertips are the concepts, metaphors and design: the fiddly symbols come from my tools. Even without an IDE, compilers and unit tests both helpfully tell me when I’m wrong. The more often I can make mistakes the more likely I am to learn not to. It is okay to be wrong about the things I am often wrong about when I program, because I have automated mitigation strategies.
Finally, programming provides positive, incremental feedback for writing and engaging with creative language. This was especially useful when I was starting out and is why I think programming may be great for dyslexic kids. “I want to make this box red” is a clear, direction, actionable goal in a way that “write in your journal for five minutes” isn’t. It also didn’t matter if it took me five tries to get it right, because each time I would get useful responses that got me closer to success. Each time I wrote something that didn’t work, I was still writing. Compare this to composing a paper, where there is no feedback at all and editing cycles tend to be much longer. Even with an outline, if a sentence didn’t make sense I’d just get lost in the paragraph. In a program, you can always hit “run” and see what happens, or write it the obviously wrong way and improve from there.
Conclusion
I will probably never be as fast a programmer as I would be if I were not dyslexic, but the other great thing about programming is that a wide variety of coders are plenty good enough to be employable and speed is only one small component of our productivity. I have been able to build on my strengths and mitigate my weaknesses to develop a successful and rewarding career. When I tell people what I build, I get to hear “I love that site!”And the greatest challenge? The biggest issues [6] all involve dealing with arrogant procedurally-minded programmers who continually over-generalize their experience [7]. Also, a word to the wise: you really never want me setting up the build system.
[0] There is not consensus that I know of on this point among experts, but I am pretty certain that there are. I have met other dyslexic folks who are very similar to me and other’s whose challenges are completely different.
[1] The neuropsychological test for this is something like “name as many animals as you can in 30 seconds who live in a jungle” and then “name as many animals as you can in 30 seconds that start with the letter C” and comparing how many are recalled in each condition.
[2] Of course, this does not mean all visual representations serve this purpose. For example, UML lacks the artsy visual features that make such diagrams super-useful to me: standardization is a great way to defeat the usefulness of drawings. I recommend getting at least three people involved in creating any visual representation that is expected to communicate to other people.
[3] The Cartoon Guide To Design Patterns is on my list of books to write someday.
[4] Especially when writing partially to figure things out myself; I don’t think in language that effectively communicates on the page. Which is why I use footnotes in almost everything I write: they are a way to express things I want to include, but most people would find distracting from the linear-ish narrative. Jokes serve a similar purpose during my talks.
[5] Many programmers are deeply invested in a privileged insistence on a freedom to be stupid, destructive or terrible coders, but who wants to work with them anyway? When faced with pushback, I now point people to The Checklist Manifesto and it’s discussion of different types of complexity.
[6] At least, the biggest issue specific to being dyslexic. The profession has other serious problems, including prevalent racism, sexism, poor management, harassment, exploitation of passion and distain for work-life balance that affect people regardless of neurodiversity.
[7] Even though a bunch of them will choke up the moment you ask them to handle CSS, unit test or employ polymorphism. But of course, anything that isn’t easy for them is obviously stupid, badly designed or not worth doing; we should be using Haskell instead. Anyway, don’t mind me, I’m only extremely bitter ;-)