Computing has no nature. It is what it is because people have made it so. - Michael Mahoney[1]

As abstract computational devices, computers are merely boxes that do what programmers instruct them to do. However, the instructions are given by white males and uphold white male desires. No one can deny that computer science is a white boys' club. Only 20% of computer science graduates are women,[2] 4% are African-American, 3% are Hispanic.[3] A 'computer' was originally a woman who performed tedious calculations by hand, and yet now their daughters and granddaughters are being driven (by themselves or others) out of the field. Why is this happening? Why is computer science such a white boys club? And looking at computer science from the perspective of the women outside the club, what can be brought to bear on this problem?

The gendering of the computer as masculine starts as early as kindergarten. Children of both genders identify the computer as masculine: the computer is a male and is for males to use.4 This translates into a difference in computer use. Boys develop a "magnetic attraction"[5] with computers before they get to school, and work to master the computer both inside and outside. They tinker with the computer, learning to take it apart and to write programs for it. Girls tend to have a muted attraction, and a gradual gaining of competence.[6]

It is not just a difference in interest. Parents tend to put a computer in the boy's room before the girl's, and fathers play more with and impart more knowledge on their sons. This is a self-reinforcing system; when these boys graduate and have kids, they will teach their sons more than their daughters. There are mothers who are programmers and fathers who will teach their daughters, but since the vast majority of programmers are men, subconscious bias keeps them focused on their sons.[7]

When men go after a computer science degree, their interest comes from their tinkering at home. They describe a need to know how the machines work. Women come to computer science through a closely related field, generally math or science. Women enjoy the problem solving and logic aspects of computing, and the relationship between computer science and these other fields. Many of these women have been conditioned to see computing as a male field, having watched their fathers or brothers playing with the computer.[8] By the time these women get to college, they have been conditioned, both consciously and subconsciously, to believe that the computer, and computer science, is a man's territory.

There is a stereotype in computer science about who succeeds: the ”geek”, the person who is so focused on computers that he or she excludes everything else.[9] However, 50% of students in computer science do not identify with this stereotype (1/3 of men and 2/3 of women) and question their place in the program.[10] These other students have a wide range of different interests — art, literature, math, philosophy, etc. —which are not represented in the computer science program.

Computer culture, especially in universities, does not value the balance of interests that these students have. The assignments in computer science are difficult, requiring lots of time and focus. Also, the “'geeks” are programming outside of class assignments. Combined, these give the expectation that all of one's time should be dedicated to programming. This expectation does not leave much time for outside pursuits. To achieve the balance I wanted in my education, I had to put my outside programming on hold, and take fewer computer science classes. That was possible here at Hampshire because I was designing my own curriculum, but that is not possible at other institutions.

Also, women suffer from "stereotype vulnerability,"[11] where a negative stereotype attributed to their gender actually causes a negative performance. In general, women do not identify with the “geek” stereotype, and this can cause them to perform worse in situations where that stereotype is an influence, even when compared to men who do not identify themselves as ”geeks.”

Jane Margolis and Allan Fisher say that women will stay in computer science "when [women] reject and find alternatives to the dominant culture of the field."[12] I don't think that this advice applies only to women; men also have other interests, and bringing alternatives to the “geek” culture can only make computer science more accessible to everyone. Margolis and Fisher go on to give 13 ways to balance the dominant culture and other cultures and interests in the computer science programming assignments.

Balance means allowing students with interests besides computer science a space to explore and express those interests:

1. Make it useful to the students. Students should be able to benefit from the programs that they are writing. This immediately brings a measure of balance to the program. In an artificial intelligence class at Mt. Holyoke College, the professor had us each work on a project that we found interesting. My project, a grammar checker, was personally useful because it could comment on my own writing.
2. Make it personal or local, by using information from their lives and their immediate communities. This can also make the assignments more useful and meaningful to the students.
3. Interface with other software. Rarely is a software project written without having to rely on an outside library or project. This both broadens the student's experience by making them think about two different software packages, but also prepares them for the “real world.”
4. Focus on usability. Usability is often ignored, because it is a design issue rather than a programming issue. But users have to be able to use the software, and increasing usability increases satisfaction with the product. It also requires a different set of skills from programming and so user interface design can interest students for whom programming is more difficult.
5. Use big data. Everyone likes learning new things. Having the computer go though gigabytes of data to generate a summary shows that the computer can be used for real tasks.
6. Use real data. By using real data, the conclusions students reach apply to their world directly.
7. Use natural language text. Parsing natural language is one of the hardest problems for computers to tackle. Having the students work on this open area is one way to make them feel powerful. Also, like my grammar checker, it is a way to interest students who are interested in language or linguistics.
8. Make it sensory by using other media besides text. Not everyone learns best through text; some prefer images, others sound, others film, and using rich media makes it easier and more interesting for these students.
9. Make it socially relevant. One of the biggest desires on the part of students with broader interests is to make their work beneficial to others. The fields of law and medicine also require a huge time commitment like computer science, but in those fields, the gender differences are slight. What law and medicine give students is a direct way to benefit others; computer science needs to make more of an effort to that end.
10. Simulate real systems. Giving students experience using the systems they may use in the real world not only gives them useful experience, but also shows them what professional software projects look like. Few projects in the real world are as contrived as those in a computer science education, and working on obviously artificial problems can be a frustrating experience.
11. Include observation. Pair programming (programming with a partner, who watches for bugs and typos, as well as being there to help with questions) is one of the best ideas to come from the Agile methodology, which focuses on bottom-up programming (a paradigm to which I will return later). It gives the watcher experience with how another person develops software and gives the programmer an extra set of eyes.
12. Bring in experts. Professors are often experts in their fields, but not all of them are. Outside experts can also show students that not all programmers are geeks so focused on programming that they ignore everything else.
13. Show how everyday computational objects work. This is the method behind Squeak, an object-oriented programming language. It lets programmers examine all facets of the environment. In an environment where you could explore the inner workings of any object you saw, you would be able to create new objects much more easily. You could either modify old objects to create new functionality, or create entirely new objects based on your experience with how the old ones worked.[13]

These are all good ways to vary the assignments and the classroom to engage students with broader interests. By allowing them to use programs to explore their world in different ways, these modifications give students with any interest an opportunity to incorporate that interest into the computer science curriculum. Balance also reduces the power of the “geek” stereotype, making it easier for the men and women who are not geeks to succeed.

As with other fields, feminist theory has made a difference in computer science. Feminist theorists show how masculine views and desires structure the field for everyone. In his essay, "Boy's Toys and Women's Work," Mahoney writes that it is in requirements analysis (the analysis of what to include in a piece of software)
"where feminism could make a difference to one field of engineering.... Feminist analysis has brought out the ways in which a world built by men hides the ways in which women make it work, and it is the working world that computer must capture if they are going to enhance all our lives."[14]

Requirements analysis for new projects determines what objects are to be modeled in software, what the user interface will be, and how the user interface and the objects will interact. Feminist analysis has shown how the software created by men subtly (or not so subtly) reinforces masculine desires: e.g. video games showing masculine models of femininity (tiny waist, large hips/breasts), or software which has a large number of options, catering to the largely masculine population of power users.

However, this view limits what feminist analysis can contribute to the science of computers. Feminist analysis of the user interface only looks at the outward view of software, the user interface. Most of the work software performs is underneath the surface the user sees. Can feminist analysis bring anything to the actual code?

Estrin asks this very question in "Women's Studies and Computer Science: Their Intersection." In computer science, Estrin sees a single-minded, masculine knowledge, a knowledge that is "largely sequential, primarily vertical and intensive."[15] Computer science is focused on instructions, on putting the instructions in the right order, on what to tell the computer to make it execute programs correctly. What Estrin wants is to bring a more humanitarian (in the sense of the human arts) knowledge to computer science.

Knowledge in the humanities is "concentric, primarily horizontal or extensive."[16] It draws multiple areas around a core, synthesizing their information. She thinks that women's studies can bring original thinking to computer science by using a more humanitarian knowledge and a more concrete style that stays closer to objects. This kind of knowledge focuses not on properties, but on relationships.

Staying closer to objects is not only possible, but is a useful way to develop software. The typical way of creating a program, the way that starts with requirements analysis, is called top-down programming, and it starts far away from the objects. Software under the design-first mentality is built in diagrams first; what parts constitute the program are written down, the relationship between those parts is determined, and each part is broken down into smaller and smaller parts.

The paradigm that works against this structuring and stays close to the objects is called bottom-up programming. Seymour Papert, famous for his work in programming education, calls this style of programming “bricolage,” from the verb bricoler (French, to tinker). Bricolage focuses not on designing from the top-down, but instead on following the work as it develops.

Claude Lévi-Strauss was one of the first to use the term bricolage to refer to this kind of intellectual work, although he used it in comparison with the constructions of myths. The key concepts of Lévi-Strauss' bricolage are:

1. The bricoleur has a limited number of objects and tools to use: "His universe of instruments is closed and the rules of his game are always to make do with 'whatever is at hand'."[17] He must create programs out of the structures that are available to him at the start of the project.
2. The set of tools is not linked to a project; "what [the tool box] contains bears no relation to the current project, or indeed to any particular project..."[18] The tools are simply what the bricoleur has accumulated.
3. Projects are chosen without regard to the tools available. The bricoleur does not "subordinate each [project] to the availability of raw materials and tools,"[19] but reuses what is in his toolbox and makes do.

Bricolage or bottom-up programming is also about following the path of the program as it develops, guiding it to the goal by making changes as the program is written; it is about a "collaborative venture with the machine."[20]

It is similar in ideology to Agile Programming, which focuses on quick revisions of a program rather than up-front choices. Instead of a strict structural specification guiding the software development, conversations with the client and functional specifications guide the development. Functional specifications are better for bottom-up programming because they do not specify how a feature needs to be implemented, just how it needs to work with the user. Most modifications would change the structure of the program, making structural specifications irrelevant; functional specifications are still useful.

The key to successful bricolage is modification, especially directed modification. However, without a plan, this often takes the form of tinkering with the program. A study of boys and girls tinkering during the debugging of a program, presented at the Association for Computing Machinery Conference on Human Factors in Computing Systems in 2006, is especially interesting. The study examined how often the boys and girls tinkered with their programs and how effective that tinkering was. The researchers also tried two different environments: one which made the tinkering easy (LowCost) and another which gave lots of feedback (HighSupport). The group that tinkered the most was the LowCost boys, confirming early assumptions about boys' use of computers.[21] However, the researchers found that tinkering was positively linked to understanding only with the girls, even given the equal skill of the students.[22]

Additionally, the boys were more likely to "engage in unproductive, repeated tinkering, which was linked to poor understanding."[23] The girls tinkered less overall, but "females’ tinkering was very effective: it was significantly tied to understanding and to successfully testing and debugging..."[24] Therefore, it would seem that males are more active bricoleurs, but that females are more effective at bottom-up programming. Females are more comfortable with and effective using bricolage because the tinkering that is required does not distract them from the real goal of a working program. Boys’ preference for a top-down programming could be explained by an aversion to situations that require repeated tinkering. Top-down programming, with its strict layout of structure, prevents tinkering by forcing adherence to that structure. Neither model is inherently better; each works well for different people.

Papert was also a strong proponent of education along the lines of bricolage intellectual activity. He called this kind of education constructionism. He, along with Sherry Turkle, advanced this idea of 'learning-by-doing' as better than the standard instructionist model. The instructionist model is how most of us were taught in school. A teacher tells the students information, which the students are expected to absorb and be able to give back to the teacher as a demonstration of that absorption. Papert and Turkle see in areas like "feminist thought and the ethnography of science"[25] a desire to work with concrete objects instead of abstractions, just as Estrin does.

Computers figure into this model of education, but "only because they provide an especially wide range of excellent contexts for constructionist learning."[26] Since the students can control the environment so much, the computer allows the students to play and construct objects that they cannot in the real world. Papert and Turkle show an example of students using both the structured model and the bricolage model to create space ships (objects that would obviously be dangerous to construct in the real world):
Some programmed their space ships as if they had read a book on 'structured programming,' in the top-down style of work that proceeds through careful planning to organize the work and by making subprocedures for every part under the hierarchical control of a superprocedure. Others seemed to work more like a painter than like this classical model of an engineer's way of doing things. The painter-programmer would put a red blob on the screen and call over her friends (for it was more often, though not always, a girl) to admire the shuttle. After a while someone might say: 'But its red, the shuttle is white.' 'Well, that's the fire!'—came the reply—'Now I'll make the white body.' And so the shuttle would grow, taking shape through a kind of negotiation between the programmer and the work in progress.[27]

The use of top-down programming is not interesting for Papert here because it is so reminiscent of the instructionist model. The hierarchical control of the subprocedures by the superprocedure is like the control of a teacher over her class. The painter-programmers are working with the computer, as well as with their classmates, to develop the space ships. The process of negotiation is how the programmers get around the limited quantity of tools and objects. When the red blob is created, it serves as the whole shuttle. But when others recognize that the project is incomplete (the shuttle must be white), the red blob is re-purposed into the fire that powers the shuttle, instead of thrown away.

As Papert writes, it was more likely for the girls to be the ones using bricolage to create programs. They developed the programs as ideas came to them, not by designing the entire program at the beginning of development. Again, the red blob was not designed to be the fire in a top-down fashion; it became the fire through the process of development.

Papert, Turkle, and Estrin have all noted a preference for bottom-up or bricolage programming from women. Why is this preference so powerful? In a study of sex differences in source code navigation, Fisher, Cox, and Zhao give a possible explanation for this difference:

[W]omen take fewer risks and accept risk only as a last resort, or when the benefits are maximised [sic] and the costs minimised [sic]. In general, women tend to choose high probability, low payoff strategies, whereas in similar situations, men tend to choose low probably but high payoff strategies ....Bottom-up program development and comprehension are low risk strategies. One works from a known position and builds using only what one knows is correct. Top-down strategies are much higher risk, as they can not be confirmed as correct until the supporting lower-level code is available. Thus, we suggest that women, documented as more risk averse, will prefer to use bottom-up comprehension and development strategies while men are more risk prone and will use top-down strategies. It is documented that women tend to program using a bottom-up approach while men tend towards using a topdown approach. Thus, it is likely that this known difference is a result of differences in risk-taking behaviour.[28]

It is a strange idea to think that the reason that women prefer bottom-up programming is a risk assessment. But the basis for that conclusion is a sensible one. If women are less willing to accept risks, in programming the best way to do that is bottom-up. Top-down programming starts at the highest level of abstraction and works downward. This means that the software will not even run until the programmer has written nearly all of the code. If something is wrong with the structure, large portions of the program may have to be rewritten. Bottom-up programming is always testable, even before all the functionality is there. A useful analogy is the building of a house. One could build the outside supports first, and then build from the top to the bottom using that structure. But it is more difficult, because one has no ground to rest on, only the structure. The easier way is to build the bottom first; then the upper levels can rest on the levels below.

The study of schoolchildren creating space ships only addresses the issue of structure. It does not address the problem of the actual code written within that structure. What about the actual code? Do females write different code than males for the same problem?

An informal study was done at a conference which asked participants to judge the gender of the programmers of two Java snippets and 2 C++ snippets. The results, perhaps unsurprisingly, were "that less than one-fifth of respondents chose all answers correctly."[29] The respondents were asked to give reasons for their choices; reasons for distinction included:

• "Female code is more explanatory with longer variable names and reasoning within comments."
• "Female code has casual commenting and neat, consistent coding layout."
• "Female code is informative and neat whereas male code tends to be sloppier and more terse."[30]

Additionally, these comments do not seem to apply to the functioning of the code, just the names and comments applied to that code. These would be comments that apply just as easily to novels written by women. These reasons seem to stem from typical notions of women as neater and more descriptive than men. If there were actually differences in the code, they were not strong enough to generally distinguish the men and women.

Despite women's preference for bottom-up programming, in short blocks of programming, there is no significant difference in women's approach to programming. The difference only manifests itself on the level of larger, whole-program structures, not on the level of block structure. This would also indicate that women are just as capable of problem-solving using the computer as men; the stereotype that “programmers are male” is just that; a stereotype, with no basis in reality.

There also is an interesting comment about the study as a whole. One person wrote:
I don’t believe this is a proper question! That is, questions like this are not based on ethical grounds. One could ask questions like (or questions like yours can lead to questions like): was this program written by a white or non-white programmer? Questions like that one (above) and yours are unethical. Just my thoughts.[31]

I'm always intrigued by people who say that some questions shouldn't be asked; this essay is a form of this question. That view seems to assume that asking the question assumes a bias on the part of the asker: that by asking “do women and men program differently?” one is looking for a difference.

I was looking for a difference in this work, but I believe that largely I have been unsuccessful. Women have a preference for bottom-up or bricolage-style programming, but that seems to be the only significant difference between men and women in actual programming. The actual act of programming, as opposed to the structure, is no different between men and women. There is an assumption that elements like comments or variable naming are cleaner or more consistent when written by women, but that too is a result of a stereotype of women. The differences in participation in computer science are due to many other factors: the difficulty of balancing other interests with the demands of the computer science curriculum, gender stereotyping against women, and the prevailing stereotype of the “geek.” With this essay, I have been attempting to work against those factors, and find what women can bring to computer science by having an alternative perspective.

Notes

1. Mahoney, Michael. "Boys' Toys and Women's Work: Feminism Engages Software." Feminism in Twentieth-Century Science, Technology, and Medicine. Ed. Angela N, H. Creager, Elizabeth Lunbeck, and Londa L Schiebinger. Chicago: University of Chicago Press, 2001. 169-185. p. 172.
2. Margolis, Jane and Allan Fisher. Unlocking the Clubhouse. Cambridge: MIT Press, 2002. p. 2
3. Ibid. p. 10.
4. Mahoney. p. 171.
5. Margolis and Fisher. p. 16.
6. Ibid. p. 17.
7. Loucks, Lisa. "Lady Doctors are Called Nurses: the Effects of Gender Bias on Elementary School Children." Prized Writing. 2001. UC Davis. 16 Apr. 2007 <http://prizedwriting.ucdavis.edu/past/1990-1991/loucks.html>.
8. Margolis and Fisher. pp. 18-9.
9. Ibid. p. 65.
10. Ibid. pp. 67-9.
11. Ibid. p. 86.
12. Ibid. p. 107.
13. Ibid. pp. 120-1.
14. Mahoney. p. 182.
15. Estrin, Thelma. “Women's Studies and Computer Science: Their Intersection.” IEEE Annals of the History of Computing. 18.3 (1996): 43-46. <http://dx.doi.org/10.1109/85.511943>. p. 43.
16. Ibid.
17. Lévi-Strauss, Claude. The Savage Mind. London: Weidenfeld and Nicolson, 1972. p. 17.
18. Ibid.
19. Ibid. p. 7.
20. Estrin. p. 45.
21. Beckwith, Laura, et al. “Tinkering and gender in end-user programmers' debugging.” CHI '06: Proceedings of the SIGCHI conference on Human Factors in computing systems. (2006): 231-240. <http://portal.acm.org/citation.cfm?id=1124808>. p. 235.
22. Ibid. p. 236.
23. Ibid. p. 239.
24. Ibid.
25. Papert, Seymour, and Idit Harel. "Situating Constructionism." Constructionism. 17 Apr. 2007 <http://www.papert.org/articles/SituatingConstructionism.html>.
26. Ibid.
27. Ibid.
28. Fisher, Maryanne, Anthony Cox, and Lin Zhao. “Using Sex Differences to Link Spatial Cognition and Program Comprehension.” Proceedings, International Conference on Software Maintenance. (2006): 289-298. p. 292.
29. Carter, Janet, and Tony Jenkins. “Gender differences in programming?” ITiCSE '02: Proceedings of the 7th annual conference on Innovation and technology in computer science education. (2002): 188-192. <http://portal.acm.org/citation.cfm?id=544469>. p. 189.
30. Ibid. p. 190.
31. Ibid. p. 191.