> made some passing comment about the CSS quality not being "ideal" or something of the sort
Not saying you weren't the subject of over-reaction, or not, but I think this is an example of sub-par feedback. It would be better to point out the issues in concrete terms, and say this is something that should be addressed, and why. And if you can't do that, you should ruminate on it until you can reify whether it is wrong, and what ought to be done, and why. Do this with anybody. If they argue with you, they'll be arguing only on technicalities, not personalities.
The other side of the same coin is whenever you receive nasty and undeserved feedback, you don't reply or argue.. You say "thank you for the feedback" and ruminate what good you can take out of that, if any. You don't fight back - not if you actually want to receive feedback in the future.
It's exactly what the article is saying: men are clamming up. If one doesn't know how to deliver excellent feedback/is worried about the packaging, the sane strategy is to just shut up. There's seldom a personal upside for delivering constructive feedback to anybody - and in a situation where bad delivery has unlimited downside, it's smart to just refrain from it.
I didn't neglect to read the article, and largely agree with its central plaint. I also agree there's a chilling effect.
I don't think it applies as much to coding practices, where you can provide specific and constructive advice and there's a concrete thing that can be debated (i.e., the changes to the code-base). What makes good business reasoning relies upon intangibles, like experience. But even here, one could point to examples of a strategy being used in the past and failing. You can't argue with the historical facts as being innately sexist. You could argue that the variables have changed, but then there's something concrete to talk about.
It has only been in recent years that I have even been able to articulate what the issues are with the code of some junior developers. I was fortunate to find "Semantic Compression" by Casey Muratori and now I have something I can point to and language to use. Before that, junior devs may have perceived the feedback as either an undue imposition of my taste, intimidation or (if any of them had ever been a woman) toxic masculinity.
Should we refrain from giving feedback before we have fully articulated the principles by which we would like our code to be written? What about the abundance of tacit knowledge that we can only hope others to learn by osmosis?
> Should we refrain from giving feedback before we have fully articulated the principles by which we would like our code to be written? What about the abundance of tacit knowledge that we can only hope others to learn by osmosis?
I think these are fair questions. Reflecting back on a younger and more arrogant self, I can see that I was quite more pushy with my opinions. And they were that, opinions. Having them challenged when I was no longer the best coder in the room was how I grew, but that required speaking in clear language, and having clear arguments. I think the sooner you learn to do this, the better, and it might challenge some bad ideas that you've held dear.
Overall, I agree with you that making bulletproof arguments is a valuable skill in the workplace.
Communicating "this is what I think of your work, some of it is negative but isn't intended as an attack against you" (without actually using any of those words, otherwise you run into the "my human trafficking shirt" problem) in a way that you're confident your criticisms won't be used against you, it's a skill you can and should train.
But it's work. Like, okay, social stuff is a part of the job, but when you're an engineer in a room with other engineers you'd like to be able to speak your mind without constantly simulating a PR team in your brain.
Going back to the OP... they were working in a consultancy roles. A consultant by definition will be liaising, communicating, generating leads, etc. and social skills are pivotal to their success. But I would say broadly for anyone working in software engineering, that effective communication is critical in an industry that's based on translating business requirements from the real world into concrete logic.
> speak your mind without constantly simulating a PR team in your brain.
Certainly not what I'm advocating. But I would say, that off-hand and unexamined opining in a collaborative setting can have a deleterious effect. Particularly if you're in a lead or senior position where your criticisms may often proceed unquestioned, even if they are based on faulty or misapplied intuitions.
In my time as a consultant, I've found I've communicated best and reached the best outcomes when I've refrained from speaking until I'm clear about what I'm saying, and why. The initial reticence allows time for less confident voices to speak their minds, and as a side benefit allow a new perspective to move the conversation.
Not saying you weren't the subject of over-reaction, or not, but I think this is an example of sub-par feedback. It would be better to point out the issues in concrete terms, and say this is something that should be addressed, and why. And if you can't do that, you should ruminate on it until you can reify whether it is wrong, and what ought to be done, and why. Do this with anybody. If they argue with you, they'll be arguing only on technicalities, not personalities.