al-king

Oh cool, his Bondi Language / Pattern Calculus was the first thing I thought of seeing this, so I guess I wasn't too far wrong.

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.

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.

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.

If anything WSL2.0 has made it clearer than WSL is a development environment, not a universal compatibility layer.

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 article is pretty up-front and unapologetic about that conceit: the argument is "that mythology isn't useful, here's a better one."

That said, it's certainly a bait-and-switch headline. Kind of par for the course.

apparently not!

ah, well, for preexisting Keybase users with linked GitHub accounts it fits that description - I found out about it because I got given some without doing anything.