21–30 of 52 posts
Since you haven’t mentioned it, have you heard of blameless post-mortems? They’re a systematic approach to this type of issue.
The mentioned problems took an emotional toll, I suspect.
Maybe we should formalize the process around this.
Thanks for your insight!
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.
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…
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.
tell them to proof read!
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.
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 th…
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 th…
Thanks for your insight. I guess his reaction deterred me from pressing the issue but that there may be no way around it.
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.
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.
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…
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…
Fortify your delivery pipeline and the problem should resolve itself.
> 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…
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.
Earlier quoted context omitted.
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…
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 muc…