"Anti-meritocracy" in software development

[Travis B.]

One idea that has come up in recent years is anti-meritocracy, in contexts such as FLOSS development. The idea is that "merit" is not equally accessible to the entire population, so by favoring it one is effectively favoring those already privileged, as the privileged have the most access to the best prep schools, the best tutors, the best family environments, and so on, even after one factors out things such as legacies to universities and like. So therefore it would be for the best to downplay "meritocracy", as it really just favors the already privileged upper classes.

Yet in the context of FLOSS development I do not see the validity of this, because "meritocracy" as applied in this context is typically judging people by their code and their software design alone, not by the many arbitrary, irrelevant, and harmful characteristics that are used to needlessly judge people. By opposing "meritocracy" one is effectively doing just that, just in a fashion inverted from how such characteristics were used to judge people in the past. Is one person's code better than another person's just because the "right" adjectives apply to them as individuals, in spite of the value, positive or negative, of their code?

And this leads to things such as tokenism, where people are superficially favored ─ or are wrongly perceived as being favored ─ because they fit the "right" adjectives rather than because of their own merit ─ which leads to resentment, both by people to whom such tokenism is applied who often feel like their actual merit is being overlooked, and by people who come to view people as undeserving due to seeing them as being favored through tokenism (even though this very often is not true in the first place). This is an area where "anti-meritocracy" would actually make things worse, not better, because anyone who is not privileged to begin with would effectively be opened up to the unfair accusation that they are being favored due things other than merit, despite how wrong such would be in most cases.

Of course, some would say that those we start out in software development are not on an equal footing, so this needs to be compensated for, but is this really true? The vast majority of the population in the First World now can afford computers, FLOSS software development tools, operating systems, and documentation are readily available to anyone interested, and so on. Today, the vast majority of people in the First World who want to engage in software development are not prevented from doing so in any fashion. And even outside the First World, a good portion of the population in places such as China and India also have such open to them.

This leads to other conclusions, such as that there are cultural factors at work rather than simple ability to engage in software development or not. I have heard this summed up by views such as "boys and their toys" being put forward as to why fewer young girls in the West get interested in software development (and why this does not apply in places such as China or India) or the circular logic that fewer women want to be involved in software development because there are fewer women involved in software development (which does not lend itself particularly well towards a practical solution).

Those pushing "anti-meritocracy" may seem to think that such would be a solution to such issues, but for the reasons I mention above to me it seems like it would cause more harm than good in that it would lead to unfair resentment of women and minorities in software development based on the very idea that they are being favored due to being the "right" people rather than due to their merits as software developers, which would likely drive them out of software development (because who wants to work in such an environment, especially one in which one is already a minority?).

That is not to say that there are not things that can be done. For instance, targeting young girls in particular to promote their interest in software development early on, so more are interested in computer science when they arrive at universities, and promoting networking amongst women in software to reduce their own perception of being isolated individuals in a largely male environment.

Consequently, I cannot help but come to the conclusion that "anti-meritocracy" in the software development world is a bad idea, despite whatever good intentions those who originally came up with the idea had. Yet I do not think that all is lost, and that there are things that can be done.

[Ares Land]

I'm not sure this is an actual issue in FLOSS. I try to stick to free software tools as much as possible, and one issue that comes up often is that a lot of projects are really tiny, to the point that getting some people to maintain them at all can be difficult.

More generally, I can be a little dubious about meritocracy at times, because 'merit' is often measured pretty subjectively.
How are programmers judged? Ideally: does the code run as expected (granted the unavoidable bugs of course), is the UI actually usable by human beings, can the code be maintained easily?

In practice the industry image of a 'competent programmer' involves things like: do they follow the latest fads? are they up to date on the latest fashionable technology? are they 'passionate' about their jobs; i.e. do they spend their time off coding, learning about new tech, attending conferences?

This image can be a pretty tough act to follow, especially for those least privileged. (A single mother won't be able to spend 70 hours a week coding and then attend the lastest XYZ User Group!)

[Raphael]

In practice the industry image of a 'competent programmer' involves things like: do they follow the latest fads? are they up to date on the latest fashionable technology?

Oh my. Personally, I'd say if "merit" means something, it should include a willingness to go against fads; but then again, I'm not Somebody Important in the software industry.

That said, I think there are some contexts where the concept of "merit" actually makes sense.

When people assert that people should be evaluated based on their merit, the standard response by critics of the concept is to ask "Merit by whose standards?" Now that, IMO, mainly makes sense if what you're used to is the world of intellectual debate. In that world, pretty much everyone is a scintillating genius according to their fans and the biggest moron in history according to their opponents. Against that background, it makes sense to respond to the assertion "People should be evaluated based on their merit" by asking "Merit by whose standards?"

But not every field is as clearly subjective as the world of intellectual debate. In some fields, there might well be something closer to a "generally applicable" standard for "merits". For instance, the merits of plumbers might be evaluated by the standards of people who want water to come out of their faucets but not out of their walls.

[Ares Land]

Oh my. Personally, I'd say if "merit" means something, it should include a willingness to go against fads; but then again, I'm not Somebody Important in the software industry.

It's more difficult in the Tech industry, because new technology and new methods do make sense. But there are fad-like phenomenon; you end up with a lot of pressure to learn about the next big thing (or fake compentence) and misapplied technology; but a lot of the time it does make sense.
Agile development models spread cult-like in the late 2000s... a lot of the time they were misapplied but they still make more sense than waterfall in many contexts.

IT is complex and moves fast, which makes it, I think, a lot harder to judge on merit than people usually think.

[Travis B.]

I'm not sure this is an actual issue in FLOSS. I try to stick to free software tools as much as possible, and one issue that comes up often is that a lot of projects are really tiny, to the point that getting some people to maintain them at all can be difficult.

More generally, I can be a little dubious about meritocracy at times, because 'merit' is often measured pretty subjectively.
How are programmers judged? Ideally: does the code run as expected (granted the unavoidable bugs of course), is the UI actually usable by human beings, can the code be maintained easily?

There are a number of ways that code can be judged ─ Does it work? Beyond simply working in common cases, is the code stable, including in corner cases? How much processor time, memory, and disk space does the code take up (the lower the better)? (As you mention) is the code maintainable? Does the code integrate well with the other code it has to work with (for code that has to work with other code)? Does the code fit a consistent style with other code it works with (for code that is part of a greater project)? (As you mention) is the code usable, especially by ordinary users not familiar with it?

In practice the industry image of a 'competent programmer' involves things like: do they follow the latest fads? are they up to date on the latest fashionable technology? are they 'passionate' about their jobs; i.e. do they spend their time off coding, learning about new tech, attending conferences?

This image can be a pretty tough act to follow, especially for those least privileged. (A single mother won't be able to spend 70 hours a week coding and then attend the lastest XYZ User Group!)

I personally roll my eyes at programming fads myself (yes, the entire Java ecosystem, you are whom I am speaking of). I am also of the view that a good programmer can learn any language they need (even though some are easier than others ─ try writing your accounting package in Brainfuck!), but simultaneously do not see the need to spend countless hours familiarizing oneself with random programming languages (since why bother when one can pick one up on an as-needed basis?). To me it is better to know, or at least be familiar with, a small but wide range of diverse programming languages (my favorites are assembly, C, Forth, Lisp, Smalltalk, Haskell, and Prolog), because from those as starting points you can learn anything else you need.

I should also note that more code does not mean better code. I personally do most of my coding outside my day job, actually ─ my day job is comprised of things such as attending meetings, testing code, whether manually or by autotesting, reading code, generating test images, and so on. It is an unusual week if I write more than, say, a page of code at my day job. And even in my own code, while my releases tend to be quite frequent, most of the time these days I do not do a huge amount of coding any given week (unless I am working on something such as updating zeptoIP to support IPv6). (I did write significantly more code than I do now at my last job, but I feel like the quality of the code I work on now is much better than what I dealt with in my previous job.)

[Travis B.]

One thing I should mention is that meritocracy in software development is very different from credentialism, which is favoring people because they went to the right schools and got the right GPA's and had the right advisors and got their papers in the right publications and so on. I personally am firmly against credentialism, because that does indeed favor the elites, and due to many factors (cough cough legacies) entirely excludes the vast majority of people regardless of their actual merit.

[Raphael]

I personally am firmly against credentialism, because that does indeed favor the elites, and due to many factors (cough cough legacies) entirely excludes the vast majority of people regardless of their actual merit.

I don't really agree with all that much of what you've written in this particular thread so far, but I completely agree with you on this.

[Travis B.]

One thing that should be remembered is that "meritocracy" has different meanings. In many cases people indeed conflate it with credentialism, based on the idea that credentials reflect merit. (As you may guess, I am very much opposed to this kind of "meritocracy".) Yet in others, such as the primary way I have been referring to it within the software world in this thread, "meritocracy" is a completely different matter from credentials. In this context, merit is equivalent to the quality of one's results (e.g. code) alone, regardless of one's credentials.