I’d wish more technical projects would focus on competent and professional engineers again. Instead, we see calls for more diversity everywhere, including this very survey. I wonder what would be the advantage of having people from different ethnical backgrounds over having people from different tech backgrounds...

The idea of focusing diversity isn't at odds with focusing on competence. The premise is that certain groups of people who do not fit the stereotype of a male, nerdy, white or asian programmer are often assumed to be less technically competent because of their appearance. As an Asian male, I can't tell you how often people assume I'm smart just by appearance alone. This leads to a hiring process that does _worse_ at hiring component engineers. Even if they are hired, the company culture might not be inclusive enough to retain them - e.g. lots of women leave the industry for that reason. This also leads to a _loss_ of talent.

It's true that some companies might do diversity poorly and hire solely to hit diversity numbers. I don't personally feel good about that. However, in practice I've seen companies that focus on diversity adopt the practice of putting more effort into reaching out to diverse candidates, but have the exact same hiring process & hiring bar applied to them. Those reasonable companies don't make the news -- after all, the unreasonable stories tend to be the ones that get attention.

Again, it's not to say that your concern never happens. However, framing diversity as if it was fundamentally at odds with competence, especially in a completely unrelated thread about a programming language, does a disservice to both diversity _and_ competence.

It seems like we might try to measure and confirm that the problem exists in the first place and to what extent. Then we might try something and measure again to see if it helped or hurt.

Black Lives Matter is just the name for a political movement and organization aligned with Critical Social Justice and specifically Critical Race Theory which actually dispenses with the idea of meritocracy as a worthwhile goal (see postmeritocracy.org for an explanation of this view; the author of that site is Coraline Ada Ehmke, author of the Contributor Covenant, which has been adopted by many projects including Golang)

The diversity you're talking about uses the definition everyone is familiar with from English.

The diversity Black Lives Matter is talking about is a technical term with the definition coming from Critical Race Theory, which defines whites as the least diverse categorically due to historically injustices against BIPOC folx.

> The idea of focusing diversity isn't at odds with focusing on competence

It is explicitly such, as stated by the movement you defend.

> The diversity you're talking about uses the definition everyone is familiar with from English.

> The diversity Black Lives Matter is talking about is a technical term with the definition coming from Critical Race Theory, which defines whites as the least diverse categorically due to historically injustices against BIPOC folx.

Can you provide a citation for that from a CRT source, not a political opponent to CRT?

> > The idea of focusing diversity isn't at odds with focusing on competence

> It is explicitly such, as stated by the movement you defend.

I think you're misunderstanding the major points of Ehmke and others. It's not that we should give up on competency being a driving factor, but instead that the set of organizational tools grouped together as "meritocracy" don't actually make competency the final end result because of the biases those tools impart. "Not a great culture fit" and all that.

Don't "overthink". Just obey corporations, don't question or doubt their agents, propagandists, storytellers("theorists"), city mayors, kapo, etc.

Competence and professionalism are not quantifiable; diversity is. Hence, when a $manager wants to improve $project (for a raise), they will invariably try to push for diversity.

This is in the context of open-source projects where identity does not matter (and is often not known).

Here's a different (and potentially offensive, please put away the pitchforks) perspective. Recently at work, I was prompted by a coworker to look at a code review page for some go code they wrote. I don't normally review go code at work, so something that struck me was that the code review comments left by a go developer seemed quite a bit more nitpicky than code reviews I'm used to seeing as a non-go developer working with non-go languages. A lot of it was minor stuff like styleguide line items (isn't that sort of stuff what go fmt and go vet are for?)

Golang is an extremely simple language (a good thing, IMHO!), but that means two things:

1) a simple language may lack safety features (e.g. anyone can ignore an err or forget to check for nil pointers), which lead to the need to compensate in other ways, which leads to:

2) the bikeshedding bar is very low in simple languages, and it can lead to institutionalizing opinions in the form of styleguide gospels or other types of "improvements" (think overuse of patterns in Java, another relatively simple language), to the point where the institutional rules put off newcomers who were expecting a breath of fresh air but instead find an "old boys club" (in the sense that they don't feel they have leverage to discuss whatever rules have been set).

I also see this phenomenon in other areas, for example, in Javascript, eslint/prettier are supposed to curb bikeshedding, yet there's an awkward dynamic when a new employee wants a new rule, and what follows is 2 hours of bikeshedding with the old guard.

Prettier lost me forever over how they handled the issue of massive (IMO correct) pushback over not allowing "break before else".

Mozilla got it right on that one.

Setting aside "right" from a technical perspective, the Prettier response to the issue was very, very disappointing.