Live data from Hacker News

How CMU increased number of women in CS from 7% to 37% [pdf]

cs.cmu.edu

31–32 of 32 posts

Re: How CMU increased number of women in CS from 7% to 37% [pdf]

#31
The author says that retention is important but I didn't see anything about either retention or graduation rates. If the "extra" women aren't graduating at a reasonable rate, did admitting them do them any good? Or, is that the wrong question?

Looking at the numbers, we see a change from 89 men and 7 women (96 total) to 83 men and 49 women (132 total) enrolled.

Looking at admission rates shows us how it was done. The women's admission rates were basically unchanged, from 34% to 36%, so the increase in women admitted and enrolled is due almost entirely to the increase in applications by women. At the same time, the overall admission rates dropped from 26% to 12%. Since the population has only two components, men and women, and the rates for women were unchanged means that the admission rates for men dropped significantly.

I wonder what relationship the admissions criteria have to success in the program.

However, the numbers suggest another question. What about the guys who were displaced by women? (There were at least 6 and no men got any of the "expansion" slots.) They get the same benefits that the rest of us get from more women in CMU CS, but they "paid" more than the rest of us. ("But for" the decision to admit women on a different scale, they would have gotten in.) Shouldn't they be compensated?

Re: How CMU increased number of women in CS from 7% to 37% [pdf]

#32
Regarding this article, I feel particularly qualified to write down my perspective since I started a comp sci program at a prestigious college in the mid-80's and was overwhelmed by the lack of support. I believe this was more than just a gender problem.

I personally didn't grok programming until years later, when I took courses with female teachers. They somehow understood what I was missing in order to develop the abstract thinking necessary to succeed in creating working software.

I didn't give up because I loved the subject matter, but it took a long long time to develop the skill set to understand the material. I had to learn how to think more the way my male friends thought. I had to focus on details that would later be less than useful to me but in order to get to the bigger picture I had a talent for, I had to "suffer" the pedantry of the male thought process.

So many times I read a comp sci text or popular "how to" book written by a man, and I would get frustrated because, I believe, men tend to learn better by giving the small, inside detail BEFORE the big picture is developed. I recall many attempts at studying assembly language and giving up because moving one bit from register to another never made sense until I understood exactly how higher level data structures were composed. All the binary math and computer architecture was never going to get me there. I could do the individual problems but could never create a picture in my head of how these small pieces fit together. At some point it just clicked. Probably after reading some books that were more appropriate for me. No teacher was ever able to communicate ideas at that level.

If you don't give me the grander scheme, the WHY, listening to the how doesn't stick.

I had a tested talent for spoken languages. I had decent math scores. I just didn't get the male patterns of thought.

Someone like me is better off learning say, C#, then the .NET CLR, then the assembly language beneath.

My career went backwards, too. I started out in high level languages, then I descended into more and more detail level comp sci until the present--I am now a C++ developer on a huge huge code base that encompasses algorithms and real computer science.

My belief is that the top-notch programmers I now work with (I mean, these people were pioneers and I am surrounded by some that literally wrote the book) are mostly from educational backgrounds where they had to learn computer architecture FIRST.

A good example of how the above ideas manifest themselves: my male colleagues don't have to Google say, the use of ftell/fseek/fgetpos. I do. Every single time. I simple don't remember. If you sat me down in a job interview and asked to apply these to say, finding a char in a string, I would write down broken code. But I have personally written several programs that utilize these functions in various ways. You would think me a complete idiot.

While my male counterparts have this sort of detail, their weakness and majority of time is spent on understanding the main goal in the first place. They ask more questions about why we are taking a certain approach (these are GOOD questions, don't get me wrong), whereas I have to spend more time actually getting syntax issues right. Not much more, but I will never be the person who just sits down and starts coding and only has to hit the compile button once or twice for it to work.

By the time the guys comprehend the why, I already have a basic specification in my head.

This talent means I "get things done" well enough for management, but my colleagues would collectively say "she's decent but not detail-minded." Why? I might forget a detail about where to put a file or leave out a case/condition that I didn't think of because I don't usually agonize over all the possible points of failure.

My approach assumes we WILL leave out a case and I write code that leaves open the possibility to modify it easily.

Reading my code, there is never any question about what to modify to make it work. I like being this person, because while my stuff breaks just like everyone else's, I can fix my stuff faster than anyone else can fix theirs.

Post reply on HN