Let me tell you what I know about gender and CS

I was very excited when one of the CS professors in my department, who had admitted he wasn't sure about the causes of gender disparity in CS, accepted my offer to share what I knew. Studying this topic has been my hobby since I stepped into my first core major CS classes and wondered where all the women went.

I've found that professors and others often want to talk about or implement their idea for a partial solution, like a mentoring program or curriculum changes, right away, without taking time to look over the root causes. It was encouraging that this professor was open to learning about the research in the field before taking action.

I based the main arc of my presentation on a book chapter by Whitecraft and Williams that Greg Wilson of Software Carpentry was kind enough to forward to me. It's an evenhanded look at much of the research in this area, including theories that are often out of favor in most places I frequent. It served as a great overview, though I felt it could have focused more on issues involving differences in prior programming experience pre-college and intimidation brought on by "nerdy strutting". (Update: I just discovered a fantastic 2012 report by NCWIT that can also serve as a great overview. It covers cultural issues more comprehensively, with more recent research and more focus on the pre-college years.)

I printed resources from NCWIT for the meeting as well. They have made the process so straightforward with their workbooks on how to increase diversity in a CS department, I can't figure out why they aren't more widely known!

The experience also reminded me how much I don't know. I ran across all the women in computing posts on Mark Guzdial's rather comprehensive blog, and realized there are so many more details to this complex problem! And I really need to read Jane Margolis's books themselves instead of everyone else's excerpts of her books.

Here is the presentation I shared with the professor, plus several slides I added afterwards. It's a bit UofA-centric, but maybe it can be useful to someone. I'm open to discussion, so let me know if you have comments :)

(Here's a link to the presentation if the viewer doesn't show up)

My hope is that this meeting will prove useful for my department. 

Code Monkey Scare You?

I was thinking about perceptions of Computer Science and I remembered a particular event in my junior year. A friend told me he had just heard a great song that reminded him of me, since I was studying Computer Science.

He messaged me a link to "Code Monkey" by Jonathan Coulton.

Thanks? [via JoCopedia]

The melody is great, and the lyrics are compelling—I've listened to it on repeat writing this post. But it's also a handy way to remember almost every stereotype of Computer Science work and workers.

I thanked my friend, but internally I was a touch offended at the connection being drawn between my field and primate-level glorified keyboard smashing. Even more internally though, I worried that maybe the song held some truth about my future if I pursued a job in software engineering. Are all stereotypes based at least a little bit on reality?

Computer Science Outreach Magic

For several months, I always carried a deck of cards in my backpack. I like playing gin rummy as much as anyone, but that's not the reason why. I carried them because I had discovered Computer Science Outreach Magic.

I learned a Computer Science magic trick from cs4fn.org/magic, and I've been hooked ever since. I've performed this trick to much success when manning booths at outreach events and teacher visiting days. It lets you engage people while illustrating a bit of computer science. At the PyLadies' lunch at PyCon '13, Esther Nam convinced me to write a blog post about this card trick I was so excited about. "Lots of people want to know how to demonstrate computer science without a computer!" she said.

Teaching the card trick to Computer Science student volunteers at the Tucson Festival of Books.

Performing the big reveal at a University of Arizona College of Science ceremony.

How to advertise your Computer Science department

(...or at least how I did)

I wanted to write this blog post because:

1. I'm proud of the brochure I made for my CS department when I was a member of the CS Ambassadors club, one year ago.
2. I realized that my CS department wasn't all that great at describing what it was about—and I imagine it isn't just my university that has this problem.
3. I believe that if a department can't describe Computer Science in an intriguing way at university and outreach events, they're throwing away a valuable method of drawing in new students. Mainly those who already know about Computer Science before college will enroll, which bodes badly for diversity in your department.

Here is the original flyer (click to enlarge if you like). To be fair, it's more an "intro to the major" brochure than an outreach brochure, which could explain the wordiness. But that can't explain the picture of a guy looking into what I assume is a chemistry machine? Or the idea that one of the best jobs you can get with this degree is Mac Genius?

I decided I wanted to emphasize a few things in my version:

• People, including women (looking back, I should have been more conscious about including minority students, but luckily I got a representative sampling of photos)
• What CS is exactly, and options for what you can do with it beyond software engineering
• Links for students to explore CS on their own, so the flyer could serve as a more general outreach tool in high schools and middle schools

Here's how it turned out! (You can click to make the images larger)

If you can find some use for my original Word document in your own project, feel free—it's here [docx, 23.3 MB]. If you don't have the font I used, it's here. I also welcome your comments for improvement!

If I were to redo it today, I'd probably search for better links for the CS-related games and resources section—maybe there is something more interactive than downloading those books I recommended. I would also try to make it look more professional. But I think it represents our department pretty well, and at least now there's something to hand out to potential students. We might not be able to compete with the gorgeous, glossy brochures from engineering without professional graphic designers, but hey, it's a start.

After the jump, see more examples of what I think makes good advertising for Computer Science departments.

Getting started in open source, PyData style

I'm attending/volunteering at PyData, and it's been great. Tutorials on pandas, Matplotlib, and NumPy were very useful, and meeting real-world data scientists is fantastic. Volunteering is a great excuse for saying hello to people (like Google director of research Peter Norvig!), as is helping attendees with their Matplotlib questions.

I was moved to blog by a panel featuring heavy contributors to major open source Python packages, including SciPy, pandas, IPython, scikit-learn, and CherryPy. This discussion and my observations of the PyCon sprints have changed my mindset: contributing to open source software has become much less intimidating! I want everyone to have this feeling, but particularly female students, because we are especially underrepresented in the OSS (open source software) world. Even small contributions to projects could be a way to impress employers, and could help change the ratio in CS overall.

The moderator asked the panelists about non-typical answers to the question of how people can get started contributing to OSS. Here are my favorite (paraphrased) quotes:

Documentation is HIGHLY needed. Improving documentation can be a great way to get started if you don't want to contribute code yet. Not only will it help you learn the project and the language, but the beginner perspective is often lacking from current documentation

Check out the pull requests on GitHub and contribute to the discussion. You can do this without having contributed any code yourself. Your perspective as a user is important.

Contribute cookbook-style examples, to help people see the forest for the trees and get into using the package. You could possibly throw it up as a gist, and/or perhaps as a IPython notebook. These are very helpful to expand the community and help developers see how to best grow the library for users. We [developers] don't see the successful use cases, instead we see the bugs.

Here were quotes that were a bit more conventional or more difficult to achieve, but still worth thinking about:

Check out the issues tracker on GitHub and see if there are any problems you can try to fix. On scikit-learn's repository we have labeled some issues "easy", so they would be good for new programmers.

Join someone who already knows what they are doing. Talk to them at sprints at conferences and perhaps code next to them. Tell them what your "pain points" are and maybe they can do something to help. In fact, developers want to know things that are issues for average users, for example: "this was difficult to understand in the documentation" or "this was tricky to use". Let us know, so we can have a friendlier product and grow the community.  

"Scratch your own itch" — discuss or fix a problem that you yourself have.

Consider helping with a project that's not so mature, you can have more influence.