Weird question but here goes.
My colleague has a strong work ethic, works hard, learns fast, goes out of his way to increase test coverage etc. I would say his contribution is net-positive but some of his work causes problems, especially when it comes to config files, shell scripting etc., so everything that is not directly caught by a linter or spell-checker.
His typo rate is quite high. I suspect an undiagnosed dyslexia.
Mistakes are often caught very late, mostly in staging, making it cumbersome. It led to a few production outages.
We have code reviews, a solid test suite etc. but typos are slipping through - once you make them, it's just harder for others to catch them.
I feel bad for him because it already led to a blame game within the team, with some asking how one can be so sloppy. I don't suspect sloppiness because he is otherwise thorough. On the other hand, it escalated because the subject is very touchy with him.
I suspect he is weirdly aware of the problem and in denial at the same time, and therefore extremely defensive.
His take is that we should increase test coverage. It is part of the answer. However, once he's involved in writing the tests, the problem is shifted to writing correct tests.
What I'm thinking about:
- engineer the problem away: adjust our tooling and config mechanisms, less strings in our configs, less dynamically-typed scripting etc.
- asking him to let AI review his code specifically for potential typos
- increasing test coverage, with other people than him writing the tests
What I am not considering:
- Telling him I suspect he has dyslexia. I'm not a doctor.
I'm trying to broaden my horizon on this issue, maybe I am missing something. What would you do?
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 eventually quit and became a middle manager at another company.
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.
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.
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.
> test suite... production outages
Have a staging or integration environment to verify changes.
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.
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.
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.
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.
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.
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.
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).
> - 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.
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.
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.
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.
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
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