Carrot, Stick, Attract, Retain, Boys, Girls

Is the shortage of women in computer science caused by a failure to attract women or are women being chased away? That seems to be at the heart of some recent discussions I've been following on the subject.

Recently one educator talked about using games as a carrot to attract women into the field. While some debated the effectiveness of this method another educator objected to the use of the term "carrot" and the idea that women needed to be attracted to the field. That educator teaches at an all female school which gives a different perspective of course. No one disputes that the number of women in the field is at a low that is not healthy but the cause is clearly up for discussion.

On the "we're chasing them away" side I submit a list of "10 Programmers you'll encounter in the field" that I came across recently. While I don't think the list is intended to be all inclusive I find it telling that there are no types on the list that I can picture many people, let alone women, aspiring to be. Those are common stereotypes that are perpetuated by the media and I fear by some people in the field and they describe a very uncomfortable atmosphere. The popular media is not particularly helpful here either.

To overcome some of that uncomfortable atmosphere, especially in education, there are resources available for teachers. Recently in the CSTA blog, Leigh Add Sudol posted a link to a practice guide from the National Center for Education Research. This guide lists five recommended strategies for encouraging girls in Math and Science. Leigh Ann has a great summary of the guide which I recommend reading if you make time for anything at all.

Several years ago I attended a training event at Carnegie Mellon (where Leigh Ann is teaching these days) that included a lot of great information about how not to to scare girls away from CS classes once there were in them. I learned quite a lot and found that these techniques helped me with a lot of the boys in my class as well.

One of the things we forget is that in the range of attitudes, confidence levels, and learning styles there is real overlap between boys and girls. Things that make some girls uncomfortable can make boys uncomfortable as well. Likewise some girls will like the same things that some other boys like. We have to make sure we don't lose site of the fact that stereotypes are not a sound basis for categorizing all students.

Comments (7)

  1. Thanks for the plug Alfred!

    I think the gender numbers are just a wake up call – not that we are "only attracting boys" but that we are only attracting a very specific subset of the population.  Girls, minorities and yes even some white males all get turned off of computer science for reasons that affect all of them.

    Its not the nature of the subject to be exclusionary and I think there are a lot of good ideas in the practice guides not about how to make CS more "fuzzy and warm" but how to strengthen our instruction and attitudes to be more inclusive.


  2. DJ says:

    "No one disputes that the number of women in the field is at a low that is not healthy…"

    I’ve got to say that it is not clear that the presence or absence of any particular sub-group of the general population has anything at all to do with the health of the field of programming/computer science. The field, by its very nature, has always attracted a very small subset of the population.  In that regard, it is similar to mathematics or any of the other ‘hard’ areas of study that require particular talents.


  3. AlfredTh says:

    DJ, I think that we really need a diversity of people and thinking in CS or any field. We’re seeing more women in math and in other engineering fields. Why not more women in CS? That is a mystery to me.

  4. Joshua Jacobsen says:

    I’m with DJ.  I’m happy to have women and minorities in computer science, but diversity (or lack thereof) is a social ideology, not an inherent problem.  Demographics should not justify the pressuring of anyone into an ill-fitted career.

    Of course, to answer your question, the difference between CS and mathematics or engineering is that CS and its rules are largely artificial.  While math and CS may be complicated in similar ways, math is a natural form of knowledge — numbers will behave the same for a long time.  Likewise with engineering and science.  Most of that knowledge doesn’t change on a basic level every few years.

    CS is an evolutionary soup of crazy technology.  It’s constantly changing and much of the change isn’t for the better.  A CS person has to completely re-learn their career every few years, often embracing a bunch of obvious junk that will disappear when the next trend emerges.  Excellence has far more to do with attitude and obsession than intelligence and a responsible work ethic.

  5. AlfredTh says:

    See I think the lack of diversity is an inherent problem. I think that things like user interface and many other things are limited by the outlooks of a monoculture of geeky men. But maybe that is just me.

    I also don’t agree that CS rules are more artificial than other engineering fields. Programmign changes to some extent but that is growth for the most part – the discovery of new rules that exist already. It takes us a while to really understand them at times but I think we discover more than we create from whole cloth.

    I do agree that we have to work towards a time when intelligence and a reasonable work ethic are more important than attitude and obsession. Frankly I think that is an area where people not currently in the field can help us.

  6. Joshua Jacobsen says:

    User interface is an area that has benefited a lot from new perspectives and I believe that it’s an area that still needs a lot more work.  Maybe culture, racial, and gender diversity makes a big difference as you suggest.  However, I can’t think of any examples that champion that belief, so I still think it’s more of an ideology.

    CS efficiency rules generally revolve around disk space, cpu power, memory, bandwidth, and such… You primarily sacrifice one for the other, depending on which is the bottleneck.  The availability and relative cost of each changes pretty constantly, and thus the rules for efficient flip-flop.  Applications change radically, too, also changing which resource is most under strain.  Today, nobody cares much about disk space if you can scavenge bandwidth or memory by wasting it.  Tomorrow, we might use non-volatile flash memory, instead, and storage will be precious again.

    In many ways, and certainly when you discuss machine operations on tiny pieces of data, you are correct — there are some solutions which will always be better than other solutions… for instance one sorting algorithm will always be better than another.

    But how often does someone write a sorting algorithm?  In modern languages, they’re included in the objects that are likely to use them.  "lst_names.sort();" and you’re done.  What you need to learn and re-learn is what the method is called, what classes implement it, and what methods and datatypes you use to put data into the linked list (or array or stack or iterator or whatever) and how to extract it.  These details change radically from year to year for no apparent reason.  In many cases, you’re at the mercy of whoever built the SDK you’re using, and that can be pretty insane for some often unexplained reason.  In the case of MicroSoft, I think an SDK is often insane because the underlying product is often released before it’s finished.

    The trend now is pushing desktop applications onto web application servers, and even individual functions (i.e. web services) are being distributed throughout a network.  Obviously this will change back, since it’s retarded.  However, it’s an entire design philosophy, repleat with unique efficiency rules and unique architectural choices that programmers need to master until we decide to abandon it.

  7. November was an interesting month in some ways. It seems that when I really lay out an opinion piece

Skip to main content