[junon]

> 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.

[tornadofart]

"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.