The importance of language and framing, part eleventy-thousand

There’s a fascinating blog post up today called “Girls Go Geek…Again” by Anna Lewis at Fog Creek Software. The post is wide-ranging and starts off by talking about the decline of women in computing since the mid-1980s:

In 1987, 42% of the software developers in America were women. And 34% of the systems analysts in America were women. Women had started to flock to computer science in the mid-1960s, during the early days of computing, when men were already dominating other technical professions but had yet to dominate the world of computing. For about two decades, the percentages of women who earned Computer Science degrees rose steadily, peaking at 37% in 1984.

In fact, for a hot second back in the mid-sixties, computer programming was actually portrayed as women’s work by the mass media.

The post links to a Cosmo article from 1967 (including an awesome quote from Grace Hopper about how programming is similar to planning a dinner party), which implies that of course women are natural programmers—why wouldn’t they be?

Then, The Great Migration out occurred (emphasis mine):

There were many reasons for the unusual influx of women into computer science. …There was a tremendous need to hire anyone with aptitude, including women. Partly, it was the fact that programming work itself was not yet fully defined as a scientific or engineering field. …

From 1984 to 2006, the number of women majoring in computer science dropped from 37% to 20% — just as the percentages of women were increasing steadily in all other fields of science, technology, engineering, and math, with the possible exception of physics. The reasons women left computer science are as complex and numerous as why they had entered in the first place. But the most common explanation is that the rise of personal computers led computing culture to be associated with the stereotype of the eccentric, antisocial, male “hacker.” Women found computer science less receptive professionally than it had been at its inception.

I’ve heard Fran Allen say similar things in the past—and, at today’s lunch for our research scholars, our speaker said something along the same lines when talking about educational technology. Once the requirements for what it meant to be a computer scientist became more “formalized” and once CS became more closely tied to engineering, suddenly it didn’t seem quite so welcoming anymore.

As interesting as the first part of this article is, the second part is equally fascinating. The blogger interviews the only female intern at Fog Creek (who, apparently, is the only technical woman on staff too!) about her experiences as a woman in CS. While the entire interview is interesting, I want to highlight two things in particular that Leah Hanson, the intern, said.

In answering the question “Why do you think younger girls or college-age women don’t go into computer science?”, she says (again, emphasis mine):

Well, I used to be baffled at how they could miss seeing how awesome programming and CS in general are, but there’s a bunch of things that seem to contribute to that. For example, women seem to give up sooner even in everyday situations with technology….Having experience with going through the frustration of trying to get some piece of technology to work, and eventually succeeding, builds skills that you need for working with technology and for debugging. Also, most girls don’t really get computers of their own when they’re young. It seems like sometimes the family computer is bought mainly for the boy to use and then he’s kind of forced to share it with his sister. That means that girls can’t experiment on computers. You need your own computer because you have to be able to possibly break it while you’re trying new stuff, without getting in trouble. …Until I had complete control of my own computer, I never had any interest in trying Linux; when someone else is responsible for keeping your computer functioning, and does a good job of it, there’s little incentive to try something like a different OS, since you’d have to convince other people that it’s a good idea to mess with what’s currently working.

This perfectly echoes the arguments in Unlocking the Clubhouse as well: women and men need the experience of tinkering so that they can get into the mindset needed for writing and debugging computer programs. Men are more likely to get the opportunity to do so. By making it socially acceptable for women to not be troubleshooters and problem-solvers of their own technology, we essentially shut off career paths to them.

And in answering the question of how Fog Creek can do a better job attracting and recruiting technical women (emphasis mine):

Well, one thing I noticed is that on your website you really stress how the developers here are the best and all the perks that you offer. But, to be honest, that doesn’t really differentiate Fog Creek from Google or Facebook because they also have awesome developers and loads of perks. Whereas what I think your internship offers that you don’t stress quite as much is all the close mentorship we get….And, basically, these things that have to do with collaboration and learning appeal a lot more to female candidates than talking about the best developers in the world or all the perks. I went to a talk at Johns Hopkins, hosted by our Women in CS group, by Hannah Wallach on gender imbalance among FLOSS developers. And she said that one of the things that happens is that women don’t even think they’re qualified for something because it’s advertised in competitive language. The language of competition not only doesn’t appeal to many women, it actually puts them off. Google advertises their Summer of Code with very competitive language. In 2006, GNOME received almost two hundred GSoC applicants – all male. When GNOME advertised an identical program for women, but emphasizing the opportunities for mentorship and learning, they received over a hundred highly qualified female applicants for the three spots they were able to fund. Honestly, when you hear the phrase “the world’s best developers,” you see a guy. And, for women, that can be alienating.

Framing matters. Language matters. We can be as inclusive and aware and welcoming as possible, but if we’re not paying attention to the language we use—on our web sites, in our course descriptions, in how we talk about technology and its role in the world—we may end up shooting ourselves in the foot.

We’re at an interesting point right now: enrollments in CS are on the rise, and more women are choosing to major in CS. We have a golden opportunity to learn from our mistakes of the past and keep the trends moving upward. Let’s hope we’re smart enough to not let history repeat itself.

Advertisement

Reflecting on the life of a teacher

This morning, I learned that one of my high school teachers, Sister Marcyann Kowalczyk, lost her battle with cancer.  Sr. Marcyann taught me European History during my sophomore year of high school.

You’re probably expecting me to say at this point that Sr. Marcyann was my favorite teacher, but the fact is that at the time, I couldn’t stand her.  She not only scared the crap out of me—-she utterly terrified me.  I was one of the smartest, most confident kids in my high school, but for an entire year I lived in abject fear of being called on by her, of being called out by her, and, worst, of failing her class.  Sr. Marcyann managed to convince me that I didn’t know a single thing about European history and that, actually, I was a complete dumbass.  As a result, I probably worked harder in that class than I did in almost any other class in high school, and probably harder than I worked in some of my college classes as well.

Part of what made Sr. Marcyann so terrifying is that you never knew what to expect from her.  One day she came into class and said that we would have to give 5 minute talks, without notes, on some aspect of Gothic architecture during the next week.  Another day she assigned 30 essays, a handful of which would appear on our next exam.  She called on people at random and asked random, hard questions—and was very good at making you feel like an idiot if you didn’t know the answer.  She gave current events quizzes (sometimes with warning, sometimes without) that could cover, literally, anything in the world, from what happened in Greece yesterday to the name of the prime minister of Zimbabwe.  On one especially memorable test day, she strode into the room and announced that the test would be a “partner test”, and that we could choose our own partners.  (It was an interesting lesson in sociology/economics, as you could see some kids immediately pair with their friends and others doing the mental calculation of “who’s the smartest person in the room”.)  She didn’t sugarcoat anything—she was blunt, to the point, and had no compunction speaking her mind.

I didn’t realize it at the time, but Sr. Marcyann prepared me better for college, for life, and for my current profession better than almost any other teacher I had before or since—and I’ve been fortunate to have had some truly excellent, inspirational teachers throughout my life.  She taught me to think on my feet, which as an educator is probably the most valuable skill I possess.  She taught me to think critically, to not make assumptions, to probe deeper into problems and facts to get the whole story.  She taught me that it’s important to have both broad and deep knowledge of a subject.  She was an amazing storyteller—I can still vividly remember her showing slides of Gothic architecture and weaving the incredible tales behind the building of that particular chapel, the politics and wars and personal struggles behind it, and being completely mesmerized.  I could have listened to her stories for hours.  When I travel in Europe, many years after the fact, I look at buildings and can tell what period they were built in and some of what was going on at the time, as well as pick out and name some of the architectural features—and this is without taking any European history since that class.

Of course, as soon as I got to college, I recognized that many of the things Sr. Marcyann forced us to do, kicking and screaming, were the very things that would help us succeed in college—knowing how to study a subject, how to take excellent notes, how to prepare for tests, how to identify and ask good questions, how to find and form study groups.  The first time one of my professors handed out a list of essays for an upcoming exam, I smiled a secret smile—I’d done this already and knew the drill! I realized that she was so tough and demanding precisely because she cared so much about us and about us not just succeeding, but thriving beyond high school.  And now that I’m an educator, when one of my former students sends me a note to say “I hated you when you made us do X, but now I do X every day in my job and I want to thank you”, I send a secret, silent thank-you to Sr. Marcyann for being such a great role model to me in this regard.

A few days ago, my high school posted a note on its Facebook page asking us to send cards and memories to Sr. Marcyann.  I had actually started to draft a note to her saying much of what I’ve said in this post.  I wish desperately now that I had taken the time earlier to do so, but somehow I sense that she will hear these words and know how much she meant to me, and to countless other SHA students.

RIP, Sr. Marcyann.  Thank you, from the bottom of my heart, from being such a terrifying, demanding, amazing teacher and human being.  You are one of a kind and you will truly be missed.

Writing backlog

Chances are good that if I ask you what comes to mind when I say “computer science”, “writing intensive” is probably not in the top 10.  Yet my job is very writing intensive, even when you take coding out of the equation.  On the teaching side, I write lectures (or “class plans”, depending on the day), handouts, assignments, exam problems, lab exercises, web posts, emails, reports, etc.  On the research side, I write grants, research papers, tech reports, howto documents for my research students, summaries of research articles, article reviews, and of course emails. Writing is the currency of research:  if you don’t write up and publish your results, it’s as if the experiments never happened, as far as the community is concerned.

This summer, I have a pretty severe backlog of writing projects.  I have 4 articles in various stages of completion:

• a journal article that was just accepted (finally!) that needs a couple of minor changes
• 2 conference papers outlining new experiments that we did last summer and winter, respectively.  One was sent out for review in the fall and rejected.  The other is at the almost completed draft stage and has not been sent out for review.
• 1 conference paper that’s purely in my head now.  We’ve got all of the data for it, but we never completed the analysis, so I have no idea if what we have is even publishable.

Normally I have writing projects in various stages, but this backlog is probably my worst in a while.  (And I haven’t even mentioned that I’ll be sketching out grant proposals this summer, too.)  Part of the issue is that I spent a lot of this year spinning my wheels, research-wise—I had students working for me all year, progress on some fronts was slower than anticipated, I had to redo some experiments and analyses, and I made some false starts on the 2 conference papers in progress.

Ideally I’d like to make progress on all of these this summer, while still leaving time to, oh, do actual new research, prep my fall classes, and pay some attention to my research students!

So, how do I prioritize?  Clearly getting the journal article finished and out is priority #1, and will also be the easiest to do (theoretically anyway).  And clearly finishing one of the drafts of the 2 papers-in-progress should be the next priority, so I can get that into the review pipeline.  But which one?  I will have to do some calculus to see which one I think is more likely to be accepted sooner rather than later.  In fact, you could argue that I should just get all the drafts-in-progress out the door and under review—clear the decks.

But.  Part of me thinks I should place some priority on that last paper, the one in my head.  I can and do get research done during the school year, but it’s often 30 or 60 minute blocks here and there.  I suspect to make traction on that paper, I’ll need some longer blocks of time to flesh things out, set up analyses, play with the data, etc.  But will doing so sap some much-needed time and energy from thinking about the more complete papers, and put me further behind on everything?

How do you prioritize your writing projects, or any other projects you juggle?