It sounds, as you point out, that he is aware of the tendency to typos and has an idea on how to guard against it. I’ve built up a similar portfolio of techniques and best practices to guard against my own shortcomings, and most of the friction I encounter is when the team I work with doesn’t have the same viewpoints on correctness and tests.
Languages like Python are the worst for exacerbating issues. Perl at least would parse the entire codebase and do some validation. Python doesn’t evaluate until runtime, meaning that unless you have 100% test coverage of all functions and branches a typo could cause an issue long after the process started.
As others have mentioned it sounds like you co-worker has good ideas. Adding test coverage, being stricter about configs (don’t ignore known keys, validate structure … as much as people hat XML, DTDs are an amazing help for catching config errors) are all things that will pay off down the road.
Long story short, instead of looking at your coworkers suggestions as a way to guard against their mistakes, take some time to understand that they live in a more chaotic worldview than you do, and have strong experience in dealing with it. Heck, put them in charge of QA processes. They sound like they’ve got the experience, and will feel better when that experience is appreciated.
I remember that i did not used to make typos but since a particular period that i vaguely rememebr i have noticed that i make more and more of them. It was some kind of switch, not a long period that the transition took place in. I could not pinpoint the reason behind it but my theory is that my speed of typing increased and with it the amount of incidence of hitting the wrong keys. I think it started primarily when my right digits hit faster than my left ones, so letters get switched. It might be neurological or i picked up some trait from some exercises related to reflexes(martial arts), hard to say but all i could recommend is typing slower or trying to write with the style of never taking your hands off the keyboard and typing with all 10 fingers instead of just few, like most of us do. Hard to switch to this style without actual desire to do so, but it is a solution.
I have also switched to mechanical keyboard because i have noticed that i was missing letters despite feeling that i hit the keys. So having more sensitive keyboard helped to mitigate quite a bit of typos. I have the brown tactile switches but i think i would go for the more sensitive red ones in the future to decrease the key travel distance for key press detection.
BTW dyslexia is more about reading rather than writing and it concerns only languages that are not phonetic.
> I remember that i did not used to make typos but since a particular period that i vaguely rememebr i have noticed that i make more and more of them.
That "rememebr" has great comedic timing :D .. but as far as I can see it's the only typo too.
I've read that aging doesn't happen in a constant rate but at some ages it accelerates. I pride myself of having a high IQ but as I get older I notice the cognitive decline. I'm not being an elitist, but it makes me wonder if the way I feel now is what people with "slower" brains feel like all the time (I've only known what it feels like inside my own brain, obviously)
Haha, good catch. I do not think that typing should fall under ageing though. And that period which I mentioned was in my early 20s, maybe even late teens. So it's not like it got worse when I hit 50(which is still far far away). I attribute it to faster typing. More speed but also more mistakes. And it is predominantly the out-of-order hit of right finder before left finger.
> The script was part of a MR, the reviewer missed the typo. We noticed it in staging.
Good!
> We introduced tests for config editing scripts after that.
Good!
> And so it went on and on... The problem is not that it happens and we then refine our processes. It is the frequency.
Honestly it looks like he’s forcing you to fortify your delivery pipelines more quickly. It may be annoying, but on the other hand, it might be a blessing in disguise. It’s a choice between paying in full now and paying over multiple years.
But I will say that trying to solve this problem by hiring more perfect humans is a fool’s errand. People will make mistakes; it’s just a question of when the resulting incident occurs and what consequences result.
If you’re using GitHub, you can use Copilot for an additional automated code review on pull requests. It’s very good at noticing typos, or refactoring issues. If you don’t Use GitHub, you can ask any LLM for an automated review before pushing (Claude Code is good at that but I assume they all work similarly).
LLM code reviews are rarely that useful but they’re good at catching the small stuff, I’ve found it to be a good addition to the normal review process
> engineer the problem away: adjust our tooling and config mechanisms, less strings in our configs, less dynamically-typed scripting etc.
This benefits everyone. Give him the tools to be self-sufficient. Especially since he seems to be aware something isn't right, let him deal with that in his own way, with dignity. What action will he be able to take by pointing out he might have dyslexia? That's a difficult problem to solve on its own, let alone knowing that your team is proverbially glaring at you from across the code review table.
Pushing for more correctness in terms of automation sets a good example; either the code is correct for the intended functionality, or it isn't. The closer you get to enforcing that, the better it is for everyone.
In another comment you mentioned JSON configs. JSONschema validation is a must here, anyway. Even it's just part of the CI/CD process. If it's types, or variables, that requires patience. Just mark those with suggestions - one for wherever it's declared, not for each usage. Marking it at the declaration site means that all other usages will also have to be updated anyway.
Anyone on your team could make the same mistake, so see him as an unintended QA step; if his main class of bug is typos in config files, that's a reflection of your codebase, not him.
in my case, i ultimately introduced linters, formatters, git hooks, gh actions, etc. i've tried to explain and tried other things, but it felt like babysitting at that point. if someone is unaware of their own weaknesses, there isn’t really much you can do about it; you'll just end up fighting, which will make both of you resent each other
make everything as code, introduce linters, formatters, hooks and checks. when you work in a small team with people of a relatively similar mindset, such things aren't necessary, but when the team grows, there will always be issues with such things. so having a mechanism to enforce rules is necessary for your own sake
My laptop is getting old, and some keys need to be pressed with more insistence and more accurately for them to register properly. It also breaks the flow, and muscle memory for things like passwords. It also lead to letter inversions, because the tonic accent need to be put on letter which need to be pressed more, rather than on the first letter of the word. It's driving me crazy but unfortunately computer are too expensive for now (and it's probably only getting worse).
I've worked with a few dyslexic developers over the years.
The answer is to just be vigilant, patient, and double-check their work.
Many IDEs support spellcheckers, so you could bump up the warning level on suspected spelling errors.
I've only rarely seen them cause run-time issues, but I guess that would be more significant in loosely typed languages where they could slip through to runtime errors more easily.
Depends on how well you know him, but if you can do that in a friendly environment... Could be worth it. I wish someone pointed out my issues if anyone actually suspected them decades ago.
It can get complicated but from a co-worker with severe dyslexia I learned that there were some proven and practical things that improved at least his reading and ability to copy text.
So... If you're close enough, maybe it's actually worth a friendly chat. I mean, you need to be a doctor to give him an official diagnosis, but not to mention you care and suspect something.
> - Telling him I suspect he has dyslexia. I'm not a doctor.
You don't have to be a doctor to tell him he might have dyslexia or something related. If he goes to a doctor to diagnose it, he'll be better off because of you. Either he'll have dyslexia and he'll know his problem or he won't and he'll start considering other causes.
People nowadays seem reluctant to offer medical advice of any kind. It's one thing to just hand him some pills, it's another to suggest he goes to see a doctor.
Could you give a few examples? I'd lean towards adjusting tooling if you can.
My spelling is often horrendous and I know it - but almost every dev I know of prefers to copy and paste anything that might be misspelled just because it's easier than taking the risk.
Similarly - how does does this get anywhere near causing a production outage?
I'd be tempted to view this as a blessing in disguise; this person sounds like they'll trip up more often than the rest, but if one individual can cause a production outage with spelling mistakes something's gone awry with your processes elsewhere. You have an opportunity to fix whatever that is now.
A string value in a json config needed to be updated.
On one prod instance, typo while updating the config by hand. Config validation of the software caught it, software stopped with the appropriate error message, a few minutes later we were up and running again.
We introduced work reviews on prod instances (similar to code reviews) after that.
Later, he then wrote a patch script to avoid making that mistake again.
In the json schema definition used in the script, the name of the property had a typo (how it came to be... no clue, copy paste should have taken care of that).
The script was part of a MR, the reviewer missed the typo. We noticed it in staging.
We introduced tests for config editing scripts after that.
And so it went on and on... The problem is not that it happens and we then refine our processes. It is the frequency.
What I’m seeing here is that you don’t have mature mechanisms to assure the reliability of your services yet. The second paragraph suggests that a misconfiguration was able to make it into production that arguably should have been caught at an earlier stage of the deployment pipeline. Anyone can make these sorts of mistakes; the fact that a particular colleague is more prone to them really doesn’t matter all that much.
Fortify your delivery pipeline and the problem should resolve itself.
They are not, but think of it like learning to play a guitar: at first, the strings cut into your fingers, but then you build up enough calluses and playing it stops hurting. Or, consider a building code: every rule was written in blood, and new buildings get safer over time.
I had a similar co-worker 12 years ago. He was a wonderful person, very positive, always nice to deal with, but he clearly had dyslexia. He would type in passwords wrong in our password manager. And he was in charge of our backups so once it came time to restore a backup you discover that none of the passwords work.
He had a terrible track record, so bad that he was passed over for the annual salary bump, he eventually quit and became a middle manager at another company.
When using Claude Code either as a CLI or VS Code extension, ask him to use /review and /security-review when he prepares his PR. These slash commands are surprisingly effective at catching mistakes, including typos. And they usually rank the severity of the mistakes. I mostly make typos in comments and the /review command always catches them and lists them as trivial but worth fixing.
This seems the obvious solution, but it might be useful to get a specific example from OP to see whether these typos can be reliably caught be automation, or if human eyes are required.
If it’s JavaScript, you can gradually migrate to TypeScript and have a Git pre-commit hook to compile (with incremental compilation). And standardise on VSCode or a derivative that makes programmatic typos obvious. Many IDEs will also spell check your strings.
I think it all comes down to him testing his work, attention to detail, and taking responsibility for making it work, just like anyone else.
I don't really think "typo" is a useful word in this context. It's a sequence of characters that... _does not work_ and _was not tested_. The fact that it is close to a different sequence of characters that would work, or that a human could recognize it for that other sequence, isn't really relevant.
Some of the engineering approaches you mention can help, but at the end of the day he has to be responsible for verifying that things work. Tests, schemas, etc. can help, but you don't want to get into a game of "the test/linter/AI didn't catch this for me, therefore it is broken".
I've worked with plenty of people over the years with linguistic quirks, like spelling insisting on spelling "deliminator", or "pluggin", or whatever, but if the code works, it works.
We run an internal, fullstack platform that developers from other teams use to make their backend systems available to end users.
To standardize design, we created grammar guidelines and fed instructions to an AI review bot. It catches about 90% of them. The rest we manage to find.
Smaller code reviews. If you are a reviewer and don't feel you are able to review something (ie. to catch the typos) within a reasonable time period, reject the review and ask for it to be smaller.
Context: severely dyslexic and have a visual stress thing too; both diagnosed, both late in life.
With that out the way. This person, unless completely not self aware, knows they can't spell and are making mistakes.
It's just a fact. Tell them to slow down and double check their work because they're making mistakes. Offer support and point them in the direction of help as appropriate per company guidelines.
But at the end of the day if they're causing issues, they're causing issues and they need to know. It's something they need to adapt to, not you to them.
You cannot engineer your way around this specific person's faults (for want of a better word). You'd have to do the same for the next person who was making mistakes.
TL;DR
Be up front and tell them they are making mistakes and need to improve. Offer support as required.
There are reasonable adjustments that can be made, when there's a know issue. But the key term is: reasonable.
Their reaction, to me, speaks of denial or embarrassment and inflexibility. They're clearly aware they have an issue.
The team though can't be coming down on them and blaming rather than adapting too. Reasonable adjustments work both ways. Team work is not about blaming individuals but about working together. Everyone has strengths and weaknesses.
Hopefully a bit more diplomatically than that, though.
But, I agree. Encourage him to go over all of his work once or twice more, and use spellchecking tools, before committing or sending out email/slack/whatever.
If he's truly dyslexic, it won't necessarily help all that much, but if he's just really sloppy it most definitely will.
It sounds, as you point out, that he is aware of the tendency to typos and has an idea on how to guard against it. I’ve built up a similar portfolio of techniques and best practices to guard against my own shortcomings, and most of the friction I encounter is when the team I work with doesn’t have the same viewpoints on correctness and tests.
Languages like Python are the worst for exacerbating issues. Perl at least would parse the entire codebase and do some validation. Python doesn’t evaluate until runtime, meaning that unless you have 100% test coverage of all functions and branches a typo could cause an issue long after the process started.
As others have mentioned it sounds like you co-worker has good ideas. Adding test coverage, being stricter about configs (don’t ignore known keys, validate structure … as much as people hat XML, DTDs are an amazing help for catching config errors) are all things that will pay off down the road.
Long story short, instead of looking at your coworkers suggestions as a way to guard against their mistakes, take some time to understand that they live in a more chaotic worldview than you do, and have strong experience in dealing with it. Heck, put them in charge of QA processes. They sound like they’ve got the experience, and will feel better when that experience is appreciated.
Yeah... perl at least ended up with 'use strict;' and 'my', python has nothing :(
I remember that i did not used to make typos but since a particular period that i vaguely rememebr i have noticed that i make more and more of them. It was some kind of switch, not a long period that the transition took place in. I could not pinpoint the reason behind it but my theory is that my speed of typing increased and with it the amount of incidence of hitting the wrong keys. I think it started primarily when my right digits hit faster than my left ones, so letters get switched. It might be neurological or i picked up some trait from some exercises related to reflexes(martial arts), hard to say but all i could recommend is typing slower or trying to write with the style of never taking your hands off the keyboard and typing with all 10 fingers instead of just few, like most of us do. Hard to switch to this style without actual desire to do so, but it is a solution.
I have also switched to mechanical keyboard because i have noticed that i was missing letters despite feeling that i hit the keys. So having more sensitive keyboard helped to mitigate quite a bit of typos. I have the brown tactile switches but i think i would go for the more sensitive red ones in the future to decrease the key travel distance for key press detection.
BTW dyslexia is more about reading rather than writing and it concerns only languages that are not phonetic.
> I remember that i did not used to make typos but since a particular period that i vaguely rememebr i have noticed that i make more and more of them.
That "rememebr" has great comedic timing :D .. but as far as I can see it's the only typo too.
I've read that aging doesn't happen in a constant rate but at some ages it accelerates. I pride myself of having a high IQ but as I get older I notice the cognitive decline. I'm not being an elitist, but it makes me wonder if the way I feel now is what people with "slower" brains feel like all the time (I've only known what it feels like inside my own brain, obviously)
Haha, good catch. I do not think that typing should fall under ageing though. And that period which I mentioned was in my early 20s, maybe even late teens. So it's not like it got worse when I hit 50(which is still far far away). I attribute it to faster typing. More speed but also more mistakes. And it is predominantly the out-of-order hit of right finder before left finger.
> The script was part of a MR, the reviewer missed the typo. We noticed it in staging.
Good!
> We introduced tests for config editing scripts after that.
Good!
> And so it went on and on... The problem is not that it happens and we then refine our processes. It is the frequency.
Honestly it looks like he’s forcing you to fortify your delivery pipelines more quickly. It may be annoying, but on the other hand, it might be a blessing in disguise. It’s a choice between paying in full now and paying over multiple years.
But I will say that trying to solve this problem by hiring more perfect humans is a fool’s errand. People will make mistakes; it’s just a question of when the resulting incident occurs and what consequences result.
"But I will say that trying to solve this problem by hiring more perfect humans is a fool’s errand."
No worries. I want to help him, not fire him. I guess the team's situation is a bit odd at the moment.
If you’re using GitHub, you can use Copilot for an additional automated code review on pull requests. It’s very good at noticing typos, or refactoring issues. If you don’t Use GitHub, you can ask any LLM for an automated review before pushing (Claude Code is good at that but I assume they all work similarly).
LLM code reviews are rarely that useful but they’re good at catching the small stuff, I’ve found it to be a good addition to the normal review process
> engineer the problem away: adjust our tooling and config mechanisms, less strings in our configs, less dynamically-typed scripting etc.
This benefits everyone. Give him the tools to be self-sufficient. Especially since he seems to be aware something isn't right, let him deal with that in his own way, with dignity. What action will he be able to take by pointing out he might have dyslexia? That's a difficult problem to solve on its own, let alone knowing that your team is proverbially glaring at you from across the code review table.
Pushing for more correctness in terms of automation sets a good example; either the code is correct for the intended functionality, or it isn't. The closer you get to enforcing that, the better it is for everyone.
In another comment you mentioned JSON configs. JSONschema validation is a must here, anyway. Even it's just part of the CI/CD process. If it's types, or variables, that requires patience. Just mark those with suggestions - one for wherever it's declared, not for each usage. Marking it at the declaration site means that all other usages will also have to be updated anyway.
Anyone on your team could make the same mistake, so see him as an unintended QA step; if his main class of bug is typos in config files, that's a reflection of your codebase, not him.
"What action will he be able to take by pointing out he might have dyslexia?"
I definitely agree, that's why I wouldn't tell him that.
The json stuff was just an example.
I see your point about the positive side of it. I guess communicating this view within the team is important.
in my case, i ultimately introduced linters, formatters, git hooks, gh actions, etc. i've tried to explain and tried other things, but it felt like babysitting at that point. if someone is unaware of their own weaknesses, there isn’t really much you can do about it; you'll just end up fighting, which will make both of you resent each other
make everything as code, introduce linters, formatters, hooks and checks. when you work in a small team with people of a relatively similar mindset, such things aren't necessary, but when the team grows, there will always be issues with such things. so having a mechanism to enforce rules is necessary for your own sake
Have you checked his physical keyboard ?
My laptop is getting old, and some keys need to be pressed with more insistence and more accurately for them to register properly. It also breaks the flow, and muscle memory for things like passwords. It also lead to letter inversions, because the tonic accent need to be put on letter which need to be pressed more, rather than on the first letter of the word. It's driving me crazy but unfortunately computer are too expensive for now (and it's probably only getting worse).
I've worked with a few dyslexic developers over the years.
The answer is to just be vigilant, patient, and double-check their work.
Many IDEs support spellcheckers, so you could bump up the warning level on suspected spelling errors.
I've only rarely seen them cause run-time issues, but I guess that would be more significant in loosely typed languages where they could slip through to runtime errors more easily.
> Telling him I suspect he has dyslexia.
Depends on how well you know him, but if you can do that in a friendly environment... Could be worth it. I wish someone pointed out my issues if anyone actually suspected them decades ago.
It can get complicated but from a co-worker with severe dyslexia I learned that there were some proven and practical things that improved at least his reading and ability to copy text.
So... If you're close enough, maybe it's actually worth a friendly chat. I mean, you need to be a doctor to give him an official diagnosis, but not to mention you care and suspect something.
> What I am not considering:
> - Telling him I suspect he has dyslexia. I'm not a doctor.
You don't have to be a doctor to tell him he might have dyslexia or something related. If he goes to a doctor to diagnose it, he'll be better off because of you. Either he'll have dyslexia and he'll know his problem or he won't and he'll start considering other causes.
People nowadays seem reluctant to offer medical advice of any kind. It's one thing to just hand him some pills, it's another to suggest he goes to see a doctor.
Could you give a few examples? I'd lean towards adjusting tooling if you can.
My spelling is often horrendous and I know it - but almost every dev I know of prefers to copy and paste anything that might be misspelled just because it's easier than taking the risk.
Similarly - how does does this get anywhere near causing a production outage?
I'd be tempted to view this as a blessing in disguise; this person sounds like they'll trip up more often than the rest, but if one individual can cause a production outage with spelling mistakes something's gone awry with your processes elsewhere. You have an opportunity to fix whatever that is now.
Example:
A string value in a json config needed to be updated.
On one prod instance, typo while updating the config by hand. Config validation of the software caught it, software stopped with the appropriate error message, a few minutes later we were up and running again.
We introduced work reviews on prod instances (similar to code reviews) after that.
Later, he then wrote a patch script to avoid making that mistake again.
In the json schema definition used in the script, the name of the property had a typo (how it came to be... no clue, copy paste should have taken care of that).
The script was part of a MR, the reviewer missed the typo. We noticed it in staging.
We introduced tests for config editing scripts after that.
And so it went on and on... The problem is not that it happens and we then refine our processes. It is the frequency.
What I’m seeing here is that you don’t have mature mechanisms to assure the reliability of your services yet. The second paragraph suggests that a misconfiguration was able to make it into production that arguably should have been caught at an earlier stage of the deployment pipeline. Anyone can make these sorts of mistakes; the fact that a particular colleague is more prone to them really doesn’t matter all that much.
Fortify your delivery pipeline and the problem should resolve itself.
Sure, it is one way to look at it. My caveat would be: Processes aren't ever perfect.
They are not, but think of it like learning to play a guitar: at first, the strings cut into your fingers, but then you build up enough calluses and playing it stops hurting. Or, consider a building code: every rule was written in blood, and new buildings get safer over time.
Most editors have some kind of spelling mistake linting extension, that should help!
We do use those, I clarified.
You don't.
I had a similar co-worker 12 years ago. He was a wonderful person, very positive, always nice to deal with, but he clearly had dyslexia. He would type in passwords wrong in our password manager. And he was in charge of our backups so once it came time to restore a backup you discover that none of the passwords work.
He had a terrible track record, so bad that he was passed over for the annual salary bump, he eventually quit and became a middle manager at another company.
When using Claude Code either as a CLI or VS Code extension, ask him to use /review and /security-review when he prepares his PR. These slash commands are surprisingly effective at catching mistakes, including typos. And they usually rank the severity of the mistakes. I mostly make typos in comments and the /review command always catches them and lists them as trivial but worth fixing.
Can you get better tools to catch his mistakes earlier?
This seems the obvious solution, but it might be useful to get a specific example from OP to see whether these typos can be reliably caught be automation, or if human eyes are required.
Updated with an example. We do, in fact, automate stuff and improve our processes, though nothing's ever perfect.
It's the sheer 'randomness' and 'creativity' of the ways typos can mess up things and the frequency that set some people off.
I am sometimes even a bit baffled.
Since you haven’t mentioned it, have you heard of blameless post-mortems? They’re a systematic approach to this type of issue.
We had that culture in the team until recently, if not that structured.
The mentioned problems took an emotional toll, I suspect.
Maybe we should formalize the process around this.
Thanks for your insight!
> less dynamically-typed scripting etc.
What dynamically typed scripting is involved?
If it’s JavaScript, you can gradually migrate to TypeScript and have a Git pre-commit hook to compile (with incremental compilation). And standardise on VSCode or a derivative that makes programmatic typos obvious. Many IDEs will also spell check your strings.
I think it all comes down to him testing his work, attention to detail, and taking responsibility for making it work, just like anyone else.
I don't really think "typo" is a useful word in this context. It's a sequence of characters that... _does not work_ and _was not tested_. The fact that it is close to a different sequence of characters that would work, or that a human could recognize it for that other sequence, isn't really relevant.
Some of the engineering approaches you mention can help, but at the end of the day he has to be responsible for verifying that things work. Tests, schemas, etc. can help, but you don't want to get into a game of "the test/linter/AI didn't catch this for me, therefore it is broken".
I've worked with plenty of people over the years with linguistic quirks, like spelling insisting on spelling "deliminator", or "pluggin", or whatever, but if the code works, it works.
We run an internal, fullstack platform that developers from other teams use to make their backend systems available to end users.
To standardize design, we created grammar guidelines and fed instructions to an AI review bot. It catches about 90% of them. The rest we manage to find.
Interesting, thanks!!
> code reviews... production outages
> test suite... production outages
Have a staging or integration environment to verify changes.
We have a staging environment. I will clarify.
Just copy-paste everything !
Bare with me - I may have had the same. Countless hours debugging. I had to copy Assembly (68000) in my early days.
Copy-paste is a life saver. Don't type this very long parameter if you can copy its name from the definition file.
Smaller code reviews. If you are a reviewer and don't feel you are able to review something (ie. to catch the typos) within a reasonable time period, reject the review and ask for it to be smaller.
Definitely will do that!
Context: severely dyslexic and have a visual stress thing too; both diagnosed, both late in life.
With that out the way. This person, unless completely not self aware, knows they can't spell and are making mistakes.
It's just a fact. Tell them to slow down and double check their work because they're making mistakes. Offer support and point them in the direction of help as appropriate per company guidelines.
But at the end of the day if they're causing issues, they're causing issues and they need to know. It's something they need to adapt to, not you to them.
You cannot engineer your way around this specific person's faults (for want of a better word). You'd have to do the same for the next person who was making mistakes.
TL;DR
Be up front and tell them they are making mistakes and need to improve. Offer support as required.
Thanks for your insight. I guess his reaction deterred me from pressing the issue but that there may be no way around it.
There are reasonable adjustments that can be made, when there's a know issue. But the key term is: reasonable.
Their reaction, to me, speaks of denial or embarrassment and inflexibility. They're clearly aware they have an issue.
The team though can't be coming down on them and blaming rather than adapting too. Reasonable adjustments work both ways. Team work is not about blaming individuals but about working together. Everyone has strengths and weaknesses.
Install a spellcheck precommit and call it a day.
tell them to proof read!
Hopefully a bit more diplomatically than that, though.
But, I agree. Encourage him to go over all of his work once or twice more, and use spellchecking tools, before committing or sending out email/slack/whatever.
If he's truly dyslexic, it won't necessarily help all that much, but if he's just really sloppy it most definitely will.
That's not how it works if someone actually has dyslexia. They often won't be able to spot the difference.
[dead]
[dead]