I think _entirely_ ignoring the kinds of considerations it covers is such a typical failure case for inexperienced programmers (or non-career coders) that it's an excellent prod to expand the scope of what enters their awareness when writing code.
Ideally folks notice discrepancies between their experiences and the things it recommends and find their taste and judgement that way, though it doesn't always work out.
So like, maybe the fact that some of the advice is clearly dreadful if you try it could be a useful wedge against the kind of cult thinking so pervasive in software. I've seen considerably more grief from people treating his SOLID stuff like a bible that clean code. YMMV.
Important to note that the book is an adaptation of content from Sussman and Hanson's Adventures in Advanced Symbolic Programming course[1]. My sense is that the 'Flexibility' angle is a bit of a misframing, making it sound more like a rough and tumble best practices book, rather than an elaboration on neglected idioms from symbolic programming that they feel deserve wider adoption, paired with blue skies ideas on how to make software robust.
My friend Phil put this together for a React Native project, when he got fed up with the mess that standard Javascript module imports and direct dependencies created when introducing testing. It's been really pleasant to use, just a solid well-thought out library.
I don't think the advice entails lower quality discourse. The prescription here, read literally, is to say the same thing, phrased in a way that invites relevant discussion.
Language emphasising subjectivity can do several things - a) you signal uncertainty so that the group has a better idea of what's really known, b) you explicitly distinguish opinion from fact, c) you invite people to share their understanding so you can get on the same page.
The emphasis seems to be less the informational (a) and (b) and more the cultural (c). It's tricky - in some sense if you're certain, you undermine the force of your opinion this way. Comparing the two communication styles there's a tradeoff between reducing friction (unnecessary? examination) and encouraging communication in general, with possible benefits for cohesion, shared understanding and expertise but also the possible detriment of communal navel gazing. If you trust the studies this refers to, encouraging equal turn-taking overall has long-term benefits for productivity.
I think both approaches have failure cases where communication becomes ineffective. Individuals will adapt to each style to different degrees, and there's no total substitute for savvy folks who are alert to social forces at play, and guide discussions when team members over- or under-play their hands.
To share the generalisation used by this piece, the suggested conversational style is more hospitable to women. Where this article talks about psychological safety, equal participation etc., I think a lot of male engineers feel safe in much more confrontational and argumentative situations than women - they can even find a kind of fun in conflict, or regard it as totally impersonal, where many women would find it deeply unpleasant and to be avoided at all costs.
> the argument is "that mythology isn't useful, here's a better one."
That's just a lame attempt to piggy-back on the name recognition of an established concept to try to funnel the spotlight on an entirely different and unrelated concept.
Different concepts are different. Thus they should be named differently, without resorting to unexcusable PR tactics.
Let's be clear: I don't think this article has created any confusion. It's manipulative, like a lot of headlines that hit the front page - you click on it expecting one thing, and find another. It's not misleading in the way poor naming in technical contexts is misleading, so I think you're somewhat guilty of conflating different concepts yourself.
The substitution is a rhetorical device to deliberately draw comparison between different ways of approaching the same goal, i.e. being more effective as a programmer.
The author, I expect, would justify the sleight of hand by saying: the audience that believes most wholeheartedly in 10x programmers is precisely the audience that needs to hear how to benefit from low-hanging fruit that will make teams more effective. Really it's an old saw, "the brilliant jerk vs. collaborative team".
You're welcome to disagree with that assessment, but I'd suggest that responding to the particular contentions in the article is more worthwhile that overinvesting in a rhetorical dichotomy which has been used for effect only.
