Quite a lot of us tech writers don’t get everything 100% right all of the time. Sometimes a small typo might elude us, sometimes we make the odd factual error despite our best efforts and research. Sometimes we phrase something clumsily, giving the wrong impression, omit some piece of information (intentionally or unintentionally), or perhaps misinterpret something we’ve read elsewhere. I’m as guilty as anyone. Especially on this blog, where I don’t always have time to proofread as thoroughly as I should. I worry a lot about being “correct”, particularly as my readership has increased over the past few years, and always endeavour to ensure my articles are as accurate as possible. It’s part of the reason why writing for others takes me so much longer than writing for myself. I always want to make sure the information I’m providing is 100% reliable. Even then, inevitably the odd mistake can slip through.
I’m grateful to be able to count on the superior knowledge of so many in the web development community. Plenty of online acquaintances have reached out with helpful pointers or corrections to articles over the years. I appreciate that they care enough to make the effort, and it has rarely felt hurtful or (worse) like mansplaining. In most cases it’s provided me with additional insight and helped me deepen my knowledge, and I try to correct my articles accordingly when I’ve got something wrong (as well as ackowledging the source of the correction).
I think most authors would want to be corrected when necessary, even if it feels a little bruising to the ego. That said, I’m a fan of giving feedback in the kindest way possible, and there are some approaches to correcting a person that are kinder than others. Because however kindly it’s meant, it can still feel kind of shitty when someone points out your flaws in public. Sure, you can tell yourself that they’re pointing out the flaws in your article/code/podcast/whatever, not your flaws as a human being. But it can still feel personal, and it takes time to build up resilience to criticism, however constructive.
And there are plenty of ways to give constructive feedback that don’t involve publicly shaming someone. You could email them. You could open a GitHub issue or PR. You could send them a DM. If you absolutely must take it public (such as on your favourite social media platform) then tone is everything. Think how someone on the receiving end might feel. Writing a short essay bulldozing their work is unlikely to make them feel good. But acknowledging the work they’ve put in is a far better approach. Something like “Great article! You might find [XYZ resource] interesting”, or “I have some additional information you might wish to consider. Do you mind if I email you?”
There are good reasons why the recipient of your feedback might prefer to keep the conversation public, but at least this way you’re giving them the choice.
Learning to take constructive feedback is a skill that can be worked on over time, but I don’t think the burden should solely be on the recipient. It’s a mark of our traditionally male-skewed workforce that the default response when someone is offended is to tell them to “be less sensitive”, rather than telling the person giving the feedback to be more sensitive. Learning to give constructive feedback with kindness and sensitivity is an important skill, and one that is too often overlooked. This applies to management, teaching, code reviews and more, just as much as it does to responding to someone’s writing.