Tag Archives: meritocracy

Restore meritocracy in CS using an obscure functional language.

Students who did not have the privilege of hacking since they were young are at a disadvantage in Computer Science (CS). However, CS departments can teach introductory programming using an obscure functional programming language to limit the young hackers’ advantage. Most students with prior coding experience learned a procedural programming paradigm, so forcing all students to struggle with learning a new, functional language helps restore meritocracy.

In the blog comments, Kite recounts hir experience with an intro CS course:

While I think my course was pretty sucky, one good thing it did was to knock the wind out of the sails of those guys who’d been programming for ages – by starting us on an obscure functional programming language called Miranda (oh did it ever raise a whole lotta grumbles from the boasters). Only after that did we do procedural stuff like C, and then onto C++. Mind you, the whole course seemed determined to be as academic and un-real-world as possible, so C++ was probably the most career-relevant thing we got out of it! [...]

Continue reading

Is requiring Open Source experience sexist?

Code Anthem’s Don’t Judge a Developer by Open Source (via Meg in the Open Thread) argues that companies that rely on Open Source coding contributions as a hiring criterion are both demanding a lot of their hiree’s free time and are sexist:

Open source is a culture. There are plenty of smart and passionate developers out there who are not part of that culture. And certainly there are plenty of dumb and curmudgeonly developers out there participating in open source…. There are there smarter ways to spend your time. The stereotypical open source developer works for a bumbling corporate during the day, doing dull work (but necessary to make money) and then comes home to work on his passion, OpenOKHRWUJ Framework…

Requiring open source contributions is sexist… Open source is dominated by men even more so than the programming community as a whole… it’s irresponsible to require your new hire developers to come from a male-oriented pool. Alas… “Underrepresentation breeds underrepresentationâ€.

I have a comment in moderation there in which I say that I think the stereotype is incorrect: that Open Source developers in my experience are either university students or other young people with a lot of free time, or they’re paid Open Source developers. (I know hobbyist Open Source coders with unrelated dev or other full-time jobs too, yes, but not nearly so many and their contributions are for obvious reasons usually not as significant. If nothing else, this group has a really high incidence of typing injuries.)

But that’s a side-note: I think the core point of the post stands. Open Source is very male-dominated, is known for being unpleasantly sexist, and is also a subculture whose norms (even where neutral as regards sexism) don’t fit everyone. Requiring these norms feeds right into the problem talked about in Being Inclusive vs Not Being Exclusive:

People who come from underprivileged minorities are usually very experienced in the art of being excluded. Sometimes it’s overt – “we don’t like your kind” – but many times it’s subtle. They’re told that they’re “not quite right”, or they “don’t have the right look”, or “don’t have the right experience”, or just aren’t told anything. At the same time, they are surrounded by all sorts of imagery and communique about how they don’t quite belong, about how they have to change themselves to fit in, about how they are undesirable. They do not see a lot of examples they can relate to; even the ones that come close tend to stick out for being “Exotic”, being a token. They already have a lot of barriers against them and are already of the mind that they’ll more likely be rejected than accepted.

If you insist on a lot of experience in a particular male-dominated sub-culture as a prerequisite for a job, that reads as “we prefer [a subset of] men, basically, or at least people willing to work hard to minimise all the ways in which they aren’t [part of the subset of] men” even if you didn’t intend it to and even if you didn’t want it to.

Code Anthem isn’t, as far as I can tell, thinking about Open Source paid jobs in that post, but they of course have this problem magnified. It seems vastly reasonable on the face of it: hiring existing Open Source contributors, ideally people from your very own community, means you hire people who are well-versed in the particular mode of development you do, in particular, the use of text-based mediums for communicating among a distributed team. Since Open Source (or more to the point Free Software) projects are at least sometimes associated with particular non-commercial goals and philosophies agreement with those seems desirable. But since most long-term Open Source developers need to be paid for it, it strongly feeds into this cycle of long-term Open Source developers continuing to be male and of a particular kind of culture, and continuing to overtly or subtly signal that that’s who is welcome in Open Source development.

Possible other posts of interest:

  • Terri’s Want more women in open source? Try paying them.
  • Dorothea Salo’s Sexism and group formation:

    A woman can be an honorary guy, sure, with all the perquisites and privileges pertaining to that status—as long as she never lets anything disturb the guy façade.

    It’s good to be an honorary guy, don’t get me wrong. Guys are fun to be around. Guys know stuff. Guys help out other guys. Guys trust other guys. And in my experience, they don’t treat honorary guys any differently from how they treat regular guys. It’s really great to be an honorary guy.

    The only problem is that part of the way that guys distinguish themselves from not-guys is by contrasting themselves with women.

FLOSS inclusivity: pragmatic, voluntary, empowering, joyous

Lucy Connor’s “Diversity at what cost?” and Benjamin Otte’s blog post on equality got me thinking about the backlash against diversity and outreach initiatives in open source. Specifically, I sometimes see arguments that inclusivity

  • is a slippery slope into coercion and quotas
  • should not be a FLOSS value, or
  • competes with the core mission of his/her software project.

In response to Otte’s thoughts on whether the principle “all men are created equal” stands in opposition to core GNOME and Fedora goals, I said in part:

The words “equality†and “inclusive†can be easy to misinterpret. Advocates often use them as a softer way of saying “don’t be sexist/racist/etc.†and “let’s give due consideration to people we’re inadvertently leaving out.†Perhaps [critics] are misreading this suggestion as greed for market share, or conflating cowardice with the intention and practice of thoughtful inclusivity.

Yes, it is an important principle that all people deserve to be treated equally *by the law*, and as an ideal to reach toward, it’s laudable. However, it’s a straw-man argument to suggest that advocates for equality and inclusion propose that all seven billion people’s opinions should have equal relevance in every endeavor and choice.

Every organization has a specific mission, such as “change the government’s policies to improve the environment†or “maintain an excellent Linux distribution with cutting-edge innovations.†This is its “value proposition,†in US English. It embodies some of its core values. The Fedora project is indeed facing a tension between its value proposition and one facet of inclusivity — suitability for novice users. But there are many other aspects to inclusivity and an interest in equality, such as accessibility, nonsexist language, university outreach, and documentation. Don’t throw the baby out with the bathwater.

You may also be interested in http://geekfeminism.org/2009/11/29/questioning-the-merit-of-meritocracy/ for thoughts on meritocracy in FLOSS.

… If you simply find any good product unstylish as soon as a certain proportion of the population starts to benefit from it, that strikes me as needlessly snobbish, and implies a misanthropy that will permanently be opposed to even the least controversial inclusivity initiatives.

We linkspammed Connor’s piece a few days ago, and commenter koipond noted:

I hear the sentiment, but it’s kind of missing the point. No one is saying “Diversity at all costs†where they want to force people in who don’t want to be there. It’s more a case of trying to break down the barriers that prevent people who might be interested but see a toxic morass and refuse to swim in the pool.

My comment was along similar lines:

When I read http://geekfeminism.org/ or the http://geekfeminism.wikia.com wiki, or listen to the women on the Systers mailing list, I don’t hear a general and undifferentiated “WE MUST GET MORE WOMEN INTO FLOSS†or tech agitprop agenda. I see lots of initiatives to help underrepresented groups — African-Americans, women, people from developing countries — get in on the joy and empowerment of hacking.

I think there is a separate argument to be made that everyone, of every gender and from every socioeconomic, ability and ethnic background, should be generally technically literate, which means being able to code a “hello world†in some decent language and feeling empowered to modify their computing environment a little. To extend the analogy, I know it ruined your [Connor's] enjoyment of Model UN when the teachers forced everyone to participate, but you’re not against the goal of everyone learning a little about how international politics works.

And because these sexist behaviors and attitudes keeping women out of high-status and high-paying professions are just now starting to fade, it’s important to take an extra look at seemingly innocuous traditional attitudes to make sure they don’t conceal yet more barriers and discouragement. As Kirrily Robert pointed out in her OSCON keynote, the community as a whole grows organically and benefits greatly from (voluntary, of course) women’s participation:

http://infotrope.net/blog/2009/07/25/standing-out-in-the-crowd-my-oscon-keynote/

Like you, these advocates like helping people. Check out http://gnomejournal.org/article/88/the-un-scary-screwdriver for an example of the kind of noncoercive, entirely opt-in outreach that most advocates, well, advocate.

As I noted to Connor: Sure, coding, and open source work, are not really intrinsically appealing to lots of people. But because there are so very many external factors keeping interested girls and women away from tech careers and open source, I’m comfortable prioritizing breaking those down, so that maybe in fifty years people’s intrinsic interests will shine naturally through. And then we’ll talk and see what interesting patterns show up.

Wanted: aggressive people with no lives

Sarah Mei just tweeted:

Whenever anyone asks why there aren’t more female developers at startups, I’m going to send them this job post. http://bit.ly/6Lsr1F

The link goes to this job ad for Mahalo:

If you’re looking for a 9-5 gig where you can keep your head down and collect a pay check don’t apply—we don’t want you. Seriously, I don’t care if you wrote the book on Python or MySQL… if you’re not a hardworking maniac who is hungry as hell you’re of no use to us. We need killers. So, if you’re a killer who wants crush it with a bunch of killer who already crushing it send me your resume.

Their benefits include:

We’ll clean your car for you and do your laundry—literally. Seriously, we don’t want you thinking about doing your laundry, cleaning your car or what you’re doing to eat—let alone spending time on that non-sense.

Who is this aimed at? Young single people, for starters. People who can move cross-country for a job. People without kids. People whose partners care for the kids. People who are aggressive. People who like working with other aggressive people, including the boss. People who are pushy enough to deal with a self-described meritocracy, or be fired. People who can identify with a long list of male names, representing people who previously enjoyed working this way.

Sound appealing to you? If not, how would you write that ad to make it more appealing?

How much is that linkspam in the window? (13th December, 2009)

If you have links of interest, please share them in comments here, or if you’re a delicious user, tag them “geekfeminism†to bring them to our attention. Please note that we tend to stick to publishing recent links (from the last month or so).

Thanks to everyone who suggested links in comments and on delicious.

Linkspam, the country where I quite want to be (8th December, 2009)

If you have links of interest, please share them in comments here, or if you’re a delicious user, tag them “geekfeminism†to bring them to our attention. Please note that we tend to stick to publishing recent links (from the last month or so).

Thanks to everyone who suggested links in comments and on delicious.

Questioning the merit of meritocracy.

In certain communities (I’m looking at you, open source), it’s common to describe the way the community functions as a “meritocracy”. The idea is that the community is led by those who demonstrate ability and skill, and in software projects, that usually means the people who write the code. Meritocracy is often espoused as being fair, in that anyone is theoretically able to rise to the top: all they have to do is demonstrate their ability.

For instance, in Jono Bacon’s recent book The Art of Community, he says:

The magic of meritocracies is that the playing field is level for everyone. Those who work hard and show a recurring commitment to the community are rewarded. Those who think that driving a car with a blue neon light underneath it will impress us are going to be sadly disappointed.

Few would argue that a meritocracy is a bad thing. Its fundamental basis is in rewarding hard work. This concept largely maps to the general life lessons that we are all raised with: work hard and you reap the rewards of your efforts.

I don’t mean to pick on Jono here, because his is only one description of meritocracy that I’ve seen. Others include PHP, Apache, and Eclipse.

But something about Jono’s description of meritocracy really jumped out for me: “the life lessons that we are all raised with.” I was lucky — let’s call it what it is and say privileged — because I did receive that message, largely through my schooling at a private, girls-only school. But it came long with other messages, from my family and society at large, like “people won’t like it if you’re too clever” and “ambition is so unattractive” and “don’t put yourself forward, dear.”

Noirin Shirley describes the situation in a blog post from 2006, FLOSSPOLS, Sexism, and Why Meritocracy Really Isn’t:

On the surface, [meritocracy is] a completely fair, non-sexist, open concept. Anyone can get in, anyone can progress, as long as they’re good enough.

That’s very, very rarely true. Generally, at best, a meritocracy turns very quickly into a merit-and-confidence/pushiness-ocracy. Good work doesn’t win you influence — good work that’s pushed in others’ faces, or at the very least, good work of which others are regularly reminded — wins you influence. And that’s where women fall down.

In short: meritocracy benefits not only those with skill and ability, but with the self-confidence to demonstrate their skill publicly and demand recognition for it. And self-confidence is highly gendered.

Noirin also writes about unconscious bias in judging merit:

The final problem with meritocracy is that even after all the noises of “it’s all about the quality of contributionsâ€, women very often aren’t judged on the same basis as men. This is one of the few areas that FLOSSPOLS have looked at where both men and women perceive there to be a problem. People listen or pay attention to women, or don’t, based on the fact that they’re female — not based on the merit or otherwise of their contributions.

This reminds me of the practice of blind auditions, where it was found that women have greater success rates in auditioning for orchestral roles when they are placed behind a screen that prevents the listener from perceiving the musician’s gender. We know that unconscious sexism plays a part in how merit is judged in other “meritocracies”; it would be naive to think that the situation is different in software development.

So when I hear someone say that their project is a meritocracy (especially if they say it as if it’s necessarily a good thing), I tend to assume that they are 1) naive, and 2) probably have a bunch of unexamined, unconscious sexism going on.

So I guess this is the part where I offer suggestions for improvement.

First up, I’d like to see projects expand the definition of merit. A pure “meritocracy” based on coding skill will lead to crappy documentation, ugly UIs, and poor community dynamics. Watch How Open Source Projects Survive Poisonous People and consider whether a poisonous person who writes good code has merit or not. Then consider any steps to seniority or leadership that are based on “merit”. Do you judge nothing but code, or do you also include other skills, including “plays well with others”, in your reviews of people’s merit?

Accept that some of your contributors will have lower “merit”, but may still be valuable, perhaps by taking on easy tasks so that more senior contributors have time to work on harder ones, or perhaps as senior contributors in training. Don’t expect people to come in with a high level of skill and ability from day one, and be prepared to accept contributions that are less than perfect. Denise Paolucci’s Teaching People to Fish is a good read on this subject for project leaders, and Angie Byron’s A diary of two developers describes a similar situation from the contributor’s perspective, showing how imperfect contributions quickly iterated can lead to a more active, collaborative community than a single perfect patch.

Finally, don’t require pushiness along with ability. To what extent do people need to put themselves forward to progress in seniority? Could you offer commit bits or leadership roles to people who haven’t asked for them, if you think they’ll do a good job? And consider “pulling” instead: ask people how their patch is progressing, and offer to review it privately. Make yourself available via a back-channel such as instant messenger and ping contributors from time to time to give them an opportunity to talk without appearing pushy.