Fonts, colors, screen readers?
I am currently teaching a teenager, it is obvious he understands principles fast and has great memory retention, but syntax is a bit of a problem. We obviously use helpful editors and IDEs in this regard, but it is still an issue.
He never graduated high school, was lacking a lot of formal training and had an understandable hostility to orthodox approaches. Our boss paired us together because I was able to find ways to make certain computer science fundamentals palatable to him. It was a wonderful, humbling opportunity to help make someone incredibly valuable even better.
People used to give this guy crap because he made lots of typos in his comments and misspelled variables. It really pissed me off because it was such a superficial critique and as far as I was concerned embarrassed the critic by exposing their inability to recognize other much more pertinent qualities. But to his credit he was also very personable and was able to defuse their foolishness, just laughing it off and preserving productive working relationships.
I would caution that this fellow's dyslexia was not an asset — it was a hindrance that he was able to swamp through immense talent in other areas and strong dedication. Not everyone brings such outrageous gifts to bear. But we all have our own gifts, and when placed in a suitable environment we can all become much better that we would otherwise.
Every training I had to overcome my dyslexia was absolutely useless. Spellcheck is very important. Fonts and colors don't matter at all. Just seeing my own work after I forgot about it, actually makes me see my mistakes. This can take years, my memory is insane for my own work.
You can't see mistakes, since you basically have an internal autocompletion that doesn't allow you to see mistakes or missing words. Checking the code of my coworkers is surprisingly different, I can find their mistakes quite easily.
It is much more important to have goal and motivation. Don't worry about those little details, like floating letters and missing words.
My monitors brightness is turned down so the white sections on a monitor with a lux meter held 5cm away is reading 33 and the room in general is about 100-130lux (I have a lux meter).
I program in a blacked out air conditioned room with a warm white light bulb behind me, so alot like what you might find in a casino lighting levels. Edit:This also helps you lose track of time and become totally absorbed in the code. In the past I even looked into buying an underground military shelter to work in so I can remove all external stimuli in order to focus on the code because the internet is a big enough distraction as it is.
The white colour on the monitor is like the Financial Times "pink" which is more orange but in time you get used to this and dont notice the orangeness.
I program with the MS night light on 50%, have used F.lux (https://justgetflux.com/) before MS introduced it.
This removes the eyestrain enormously so you can spend hours in front of the monitor and ignore the "take regular breaks to avoid eye strain".
I prefer windows ClearType to be off so I can see every pixel in the font like windows 2000/XP, not these new ones which are all smoothed.
Have the "show location of mouse pointer when CTRL is pressed" switched on as its easy to loss the mouse on multiple big monitors.
OS 120dpi font size System Font size 18, but this depends on the size and resolution of your monitors, so you'll need to experiment with your fonts.
Basic text editor a little better than notepad but not as good as notepad++. No code autocomplete or anything.
ALWAYS ALWAYS close your parenthesis/brackets/quotes as soon as you open them then go back to write what's in them. So, if I write: func(arg), the keystrokes for me are: f u n c ( ) <- a r g and it's muscle memory at this point.
Color syntax highlighting is a must! It lets you know your keywords are correct.
Copy-and-paste variable names. Write them once and then get fast at copying them.
And then some preferences I like, not sure if they're related:
I prefer coding styles with lots of vertical white-space. I also rotate my monitors to portrait.
Also, I've always used a dark mode theme. I thought that was a nostalgia for the old DOS days, but seeing other people recommend them, maybe it's a thing?
I think it might be helpful if you could say specifically what are they having issues with. what is triggering things and where.
As for fonts/colors/etc.. I always use mono spaced fonts, and ones that make clear distinctions between all characters (0/O) (I/l) etc...
I use dark themes but I don't think that helps with the issue, and is just a personal preference. I can't imagine using a screen reader and it not being horrible, code is far to many characters with specific meaning, for a reader to read them out would be minding numbing.
Use JetBrains mono-spaced font.
Use three big desktop LCDs, with largish font, green characters on black background and vim syntax highlighting.
Edit my code on the middle monitor and have reference information on the monitors on either side. Copy 'n paste rather than re-type stuff. Heavy use of keyboard short-cuts, avoid mouse when editing, etc. Lots of ALT-TAB switching between windows (Mate/Debian/Linux).
Quietly read aloud to myself to check spellings, etc. User spelling auto-correction.
Use a fast machine and frequently re-compile individual files with maximum warnings level to get the compiler catch my typos.
The other thing I struggle with is being able to recall things in detail from what I have previously worked on. "What was x called that did Y you were working on last week?" I really struggle with that style of question.
For the spelling of variables names I use vim with spell check and mostly use ctrl+n to complete words so that they are spelt the same throughout. For the memory of function names being able to spin up a repl or run a subset of unit tests/ google/ autocomplete based on the estimated available properties of an object normally get the job done.
There are some really nice spell checks that integrate with vim that check the spelling of the words broken up by underscore so that each is checked individually. That helps a lot when writing a variable for the first time.
I always have to triple check numbers, I often try grouping them in a few different ways, e.g. 327895 I would read as 32-78-95 and then again as 327-895 just to be sure I have not transposed any digits.
Other than this sort of discipline I have not found a solution.
Only thing I've noticed is that the way we absorb information and master it is very different from some of my colleagues. RTFM is really a struggle, and instead I do better learning through a million smaller pokes that slowly build familiarity (e.g. videos + playing with actual code, even if you don't fully grasp it).
I struggled more in college with contrived examples and math-like definitions, but you show me how it works and it working, and I get it very quickly.
As far as fonts/IDEs? Nothing unusual, just a high quality code font (monospaced, like Cascadia Code, Jetbrains Mono, etc), with normal autocomplete/AI suggestions. I do set my DPI to 125% but that may be an eyesight/personal preference thing.
But that much you've found out, I think discipline and good habits are what's most important.. Let's assume they won't become great at spelling, and not waste too much energy there, but instead focus on the mechanics around avoiding it becoming an issue.
The IDE will help with what's already in the language/codebase, and assuming those are spelled correctly, autocomplete makes it hard to mess up. The problem is new names, because they will proliferate throughout the codebase, while they may be easy to refactor internally, they will be challenging when they're exposed through some API.
My suggestion is that new names are verified by searching for them on a search engine and/or using a dictionary, not only to verify their spelling, but as importantly, to verify their meaning, (I've encountered correctly spelled words that just meant something completely different because spellcheck was used, but the word wasn't looked up in a search engine to find out if it actually meant what they thought).
Newly added names that has been added, can be kept in a list for quick copy-paste access to them while being used throughout the code-base, until autocomplete can reliably use them.
Another hint during "verification" is to avoid similar looking or sounding names if possible, but that's applicable to everyone, dyslexic or not.
My dad is as well and he did the same course but as an adult.
Then he partnered with some dyslexia specialists and wrote the first version of unitsofsound[1] (recently sold to nisai), I joined him and help with the re-write to the web version in the early 2000's
I would say that day-to-day the problems are more going to be related to reading that writing IMHO. The act of writing code is heavily supported with linters & compilers etc etc and so typo's don't tend to be a huge problem
Dyslexia usual manifests with short term memory difficulties, I tend to rely heavily on a pen & paper notepad with scribbles.
However, in the actual workplace, it can have its advantages. Dyslexics are encouraged to draw diagrams and other such visual ways of helping with memory & disseminating information (pictures worth a thousand words and all that)
When it comes to practical tips for learning ...
- learn how to read documentation - I find ligatures are useful (see visual clues) - thesaurus for naming things - practice practice practice, pushing syntax into long term memory rather than short term will be the key. Maybe reduce syntax to being with by concentrating on variable & functions to write in an FP style
I hope this helps and feel free to contact me to talk about it some more chris [at] matheson.it
The best trick I have found is having my work, and code read back to me using text to speech software.
Reading along as the computer speaks helps me to find spelling and grammar mistakes.
Now most of it is catched by tab completion, types and linting. That increased my joy of coding a lot.
Overall I like to code as you break down your intent into small statements. In high school I had to read and write long and convoluted texts and that was a pain. I made more then 25 mistakes on a single page during exames. Getting into software felt empowering as this did not matter anymore. There are still syntax errors in my code but I can fix them rather quickly without thinking to much about it.
They didn't have much trouble with code, but reading specs was a pain.
I learned shorter sentences and more whitespace between them helped.
And, of course, brevity.
As others have mentioned, it’s all about motivation. The longest books I read as a kid were programming books - I got through them because I was motivated to learn. I’d recommend challenging him with puzzles - find something level appropriate such “print a pyramid with base size n” or “draw a maze that doesn’t loop back on itself” for advanced beginners.