Tag Archives: meritocracy

Meritocracy? Might want to re-think how you define merit.

Rock on!
You might think if you put together a lot of smart people, you’d get a smart group, but new research into group intelligence shows that’s not always the case. (For those of you who don’t have access to online journal subscriptions through your local library or university, there are more details in the Carnegie Mellon University press release.)

What we found is that the intelligence of the team members was not significantly related to the collective intelligence, either positively or negatively.

[...]

Our first observation and the one that surprised us the most was that the proportion of females in the group seemed to be strongly predictive of the collective intelligence of the group.

However, when they looked more closely they realised that it wasn’t the gender that mattered, but rather the social sensitivity of the group members (previous studies had shown that women tend to score more highly in social sensitivity).

It’s not the intelligence of the group members that matters; it’s their social sensitivity.

So the more your group members were socially sensitive, the better the group performed in measures of collective intelligence. The key here was that group members need to collaborate, and to do that they needed those social skills to help them work together. This includes some different conversational patterns: groups where one or two people dominated conversations exhibited low collective intelligence, while groups where more people contributed had higher collective intelligence.

This scientific research is potentially a big blow to the standard “meritocracy works” theory often espoused in open source and computing groups. Standard meritocracy rules say you do clever things and you get accepted, and this will make for perfectly good teams. But given that there’s often bias that dismisses “soft skills,” it turns out that folk may actually be using typical geek meritocracy rules to weed out some of the people we need to make the group most effective as a whole.

Some of my female colleagues would like to conclude that you simply just need to hire more women. While that might be easier, what it really suggests is that you need to pay attention to what people refer to as these “softer skills” and thinking about who’s going to be a good team player, not necessarily focused solely on individual achievement, individual accomplishments.

So if you want to claim that the best way to build tech teams is meritocracy… you might want to think more carefully about how you define merit.

Rock show DS

The quotes in this article are drawn from Bob McDonald’s conversation with Dr. Anita Williams Woolley, the lead author, on the Quirks and Quarks interview aired October 9. You can download the podcast of the segment on collective intelligence here.

Social problems in Computer Science

This is a guest post by Jessica Hamrick. Jessica Hamrick is a student at the Massachusetts Institute of Technology pursuing a bachelor’s degree in computer science with a bent towards artificial intelligence. She is is the current Chair of MIT’s computer club (SIPB), and when she is not busy managing that, enjoys hacking/coding, photography, knitting, and blogging at Artificial Awareness

This entry is cross-posted with some edits.

This morning, I read a blog post about women in computer science which was quite compelling. It reminded me, of course, of another article about women in CS, and I began thinking about about what my own opinion is on the subject. Sexism in CS and similarly technical fields is certainly a problem. But why? And how have I encountered it?

It struck me that I am incredibly lucky to be a student at MIT, where I have never actually encountered blatant sexism. No one has ever groped me, or told me I was incompetent because I was a woman (nor have I ever felt that was the case). I was elected SIPB Chair, but it was not that people thought I was sexy or that I slept with anyone, but that I was the right person for the job. When I ask more experienced hackers technical questions, they don’t try to gloss over the details or tell me that I won’t understand–they explain it the same way they would to anyone else. Really, I couldn’t ask for a better environment.

However, it still didn’t feel quite like sexism (or something like it) it was entirely absent. After thinking a while longer, I realized what the problem was:

The tech environment walks a fine line between being elitist and being a meritocracy, and often manages to slip back into elitism.

It’s not so much a problem of sexism as it is a problem of general attitude. Becoming good at dealing with computers takes a lot of hands-on experience. There aren’t any classes that will teach you how to debug NetworkManager or how to reconfigure your X configuration so that gdm doesn’t fail. So those of us who like figuring out the answers to such problems have only a handful of options: 1) learn everything using Google, 2) learn everything by asking an expert, 3) both 1 and 2, or 4) give up. Sometimes, if the problem is specialized enough, 2 and 4 are really the only options. Unfortunately, it is often the case when asking an experienced hacker that they will give a harsh, unhelpful, and/or elitist response. Here’s an example.

Person A: I need to reinstall this computer with Debian, but I don’t have a CD or DVD burner or any flash media. I’m not sure if I have any other options. Could you help me?

Person B: I don’t have time. Just use PXE.

A (thinking): PXE, what’s that? I guess I’ll Google it. Hmm, well, Wikipedia says it’s a way of booting your computer over the network. I guess sort of like a livecd, except over the network? That’s kind of cool. How do I do it? This site seems to give some links. Looks like the Debian link is broken, so I’ll use the Red Hat link and see if I can just change the relevant things.

[an hour passes]

A (frustrated): This isn’t working. How am I supposed to install my computer over the internet if I have to install stuff to the computer to begin with? I don’t understand how this works!
B: … what the hell are you doing? You just choose the “netboot” option in your BIOS, like you would choose to boot from CD-ROM or hard drive, etc.

Do you see what Person B did wrong, here? Person A was asking for help, and clearly does not know about netbooting (or they wouldn’t have asked). Person B assumes they know what PXE is and that they know how to use it, or at least that they can figure it out for themselves. Unfortunately, the documentation on PXE is unhelpful and misleading and never mentions needing to change a setting in your BIOS. Person A tried to figure it out themselves using the vague information given to them by Person B, but only managed to waste an hour and become even more confused! Furthermore, when Person A comes back for more help, Person B acts like they are incapable of learning for being ignorant and confused, and treats them with disdain. It would have been so much nicer, faster, and easier for Person B to simply say in the first place “try using the netboot option in your BIOS to boot into the installer over the internet”.

In my experience, the sort of attitude taken by Person B, either intentionally or unintentionally, is the most formidable obstacle facing new tech-oriented people. In particular, I have noticed that men tend to be better at muscling their way through this “barrier of newbie shame”. Many studies have shown that women tend to be less confident and less assertive than men, and when the environment is such that you have to be assertive and confident in order to get anywhere, it is no wonder that many choose to give up and choose a different path. Being ignorant of a topic does not mean you are incapable of learning it, but many people in CS act like it does.

There is no reason why the tech environment should be so elitist. I heartily agree that it must retain a degree of meritocracy: you need to earn your respect as a hacker. However, everyone has to start somewhere; no one is born with awesome hacking abilities, and not everybody is as able to figure out how things work without a few pointers. Wouldn’t it be so much better to have more skilled people in computer science, to fix even more bugs and create even more brilliant pieces of software? I believe that if we could tone down the elitism, such a world would become a reality.

Unfortunately, it’s not as easy as just recognizing what the problem is. Being elitist is not always a conscious or deliberate action (most people are not so much of an ass to say “I won’t be helpful because I am better than you”) — it is usually just the easy way out. Becoming a hacker in an elitist environment makes it all too simple to just assume that that is the correct way of doing things. It is easy to fall into the mindset of “I had to deal with and stand up to that sort of bullshit when I was new, so why shouldn’t everyone else?”. It is easy to find yourself too busy to really help, so you just brush them off with a short, unhelpful answer or tell them to RTFM. It is easy to forget that you were once the confused, ignorant newbie who didn’t have the background that you now do.

In addition, I think that many people become rough and abrasive because they are all too often asked to fix things themselves as opposed to giving advice. Every tech person is all too familiar with friends, relatives, and acquaintances asking them to fix computers or install software, and most tech people I know hate it. It is especially frustrating when people who are nominally technically competent ask you to do things for them. The urge to say “no, go figure it out yourself!” is extremely strong, and it is easy to lump favor-seekers into the same category as advice-seekers. But it is important to make the distinction, and to actually be helpful when someone asks for advice.

So, how can we fix this problem? Recognizing that it is a problem is a first step, but it is not enough. Changing things will not be quick or easy, either. But, there are a few things we can try:

  1. If you are too busy to help, politely say so and apologize that you don’t have the time. Don’t give vague or cryptic answers.
  2. Don’t assume that they have the same background of knowledge that you do, because they probably don’t. Try to explain things at their level. That doesn’t mean &#8220skip the details”, but &#8220make sure to explain the details and include relevant pieces of knowledge that you have but they don’t”.;.
  3. Point them towards documentation which you know is helpful, instead of just throwing terminology around.
  4. Be polite, even if they are asking what seems like an unintelligent question or asking you to do something for them You can say “no, that’s not my job” or “no, I don’t have time right now” without being rude and abrasive.

From now on, I will try to point out this phenomenon of elitism to people I know in CS, and encourage them to be more conscientious of their interactions with aspiring hackers. I hope that you will, too! I’d also love to hear any other opinions on this matter. Have you encountered this elitist environment elsewhere? How have you dealt with it?

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.