05.20.09
Gender and programming
I had a very brief but very interesting talk with Prof. Margaret Burnett. She does research on gender and programming. at Oregon State University, but was in town for the International Conference on Software Engineering. She said that many studies have shown that women are — in general — more risk averse than men are. (I’ve also commented on this.) She said that her research found that risk-averse people (most women and some men) are less likely to tinker, to explore, to try out novel features in both tools and languages when programming.
I extrapolate that this means that risk-seeking people (most men and some women) were more likely to have better command of tools, and this ties into something that I’ve been voicing frustration with for some time — there is no instruction on how to use tools in the CS curriculum — but I had never seen it as a gender-bias issue before. I can see how a male universe would think there was no need to explain how to use tools because the figured that the guys would just figure it out on their own. And the most guys might — but most of the women and some of the men might not figure out how to use tools on their own.
In particular, there is no instruction on how to use the debugger: not on what features are available, not on when you should use a debugger vs. not, and none on good debugging strategy. (I’ve commented on that here.) Some of using the debugger is art, true, but there are teachable strategies – practically algorithms — for how to use the debugger to achieve specific ends. (For example, I wrote up how to use the debugger to localize the causes of hangs.)
Full of excitement from Prof. Burnett’s revelations, I went to dinner with a bunch of people connected to the research lab I did my MS research in. All men, of course. I related how Prof. Burnett said that women didn’t tinker, and how this obviously implied to me that CS departments should give some instruction on how to use tools. The guys had a different response: “The departments should teach the women how to tinker.”
That was an unsatisfying response to me, but it took me a while to figure out why. It suggests that the risk-averse pool doesn’t know how to tinker, while in my risk-averse model, it is not appropriate to tinker: one shouldn’t goof off fiddling with stuff that has a risk of not being useful when there is work to do!
(As a concrete example, it has been emotionally very difficult for me to write this blog post today. I think it is important and worthwhile, but I have a little risk-averse agent in my head screaming, screaming at me that I shouldn’t be wasting my time on this: I should be applying for jobs, looking for an immigration lawyer, doing laundry, or working on improving the performance of my maps code. In other words, writing this post is risky behaviour: it takes time for no immediate payoff, and only a low chance of a future payoff. It might also be controversial enough that it upsets people. Doing laundry, however, is a low-risk behaviour: I am guaranteed that it will make my life fractionally better.)
To change the risk-averse population’s behaviour, you would have to change their entire model of risk-reward. I’m not sure that’s possible, but I also think that you shouldn’t want to change the attitude. You want some people to be risk-seeking, as they are the ones who will get you the big wins. However, they will also get you the big losses. The risk-averse people are the ones who provide stability.
Also note that because there is such asymmetry in task completion time between above-median and below-median, you might expect that a bunch of median programmers are, in the aggregate, more productive than a group at both extremes. (There are limits to how much faster you can get at completing a task, but there are no limits to how much slower you can get.) It might be that risk aversion is a good thing!
There was a study I heard of second-hand (I wish I had a citation — anybody know?) that found that startups with a lot of women (I’m remembering 40%) had much MUCH higher survival rates than ones with lower proportions of women. This makes perfect sense to me; a risk-averse population would rein in the potentially destructive tendencies of a risk-seeking population.
Thus I think it does make sense to provide academic training in how to use tools. This should perhaps be coupled with some propaganda about how it is important to set aside some time in the future to get comfortable with tools. (Perhaps it should be presented as risky to not spend time tinkering with tools!)
UPDATE: There’s an interesting (though all-too-brief!) article that mentions differences in the biochemical responses to risk that men and women produce. It says that men produce adrenaline, which is fun. Women produce acetylcholine, which the article says pretty much makes them want to vomit. That could certainly change one’s reaction to risk..
Jank said,
May 20, 2009 at 2:56 pm
Interesting discussion. I can’t comment much on the specifics of your arguments, but what you write remind me of so many discussions about cultural differences and value differences that I’ve had with my wife, colleagues, students and other people who do a lot of things in weird ways, i.e. people who don’t think like me, don’t have my cultural background, etc. etc. 🙂
It’s extremely hard to discuss values and stay neutral, and I smiled to myself when I thought I caught you out in this article, namely regarding the survival rates of startups related to the gender mix in the startup. Survival isn’t necessarily the end-all, be-all for startups. How about degree of success? A risk lover could counter your story like this: Yes, some testosterone fueled startups bet big and fail, but some testosterone overdosing startups bet big and make all the founders millionaires, whereas hormone-balanced startups bet low and (only) give all the founders steady jobs and the ability to pay off their car and their one bedroom apartments.
As in so many other culture / value discussions, I think it’s a matter of fitting in. What level of risk aversion is required for the developer? Depends on their environment, i.e. their product, their customers, etc. Banking software and gaming engines might be on opposite ends of that scale(?)
As for the startups, what level of risk aversion does the business environment expect? A couple of extremes: In Denmark (one of the safest societies in the world in almost any way imaginable) having failed with a business is a stigma. I visited Silicon Valley in 1998 and got the impression that if the founders of a new startup hadn’t been involved in one or two startup business failures, then investors would think they were sissies and they’d be reluctant to take a chance on the new startup.
Wicked Teacher of the West said,
May 21, 2009 at 6:10 pm
I’m not sure there’s enough research about attitude towards tinkering.
My hypothesis – as a teacher at a girls school that teaches both programming and engineering – is that tinkering can be taught. And that tinkering is inherently a rewarding experience, so people who are enticed (or forced) to try it will develop it as a habit.
The reality is that I agree with both you AND your peers. I think we should “teach” tinkering – or at least explicitly encourage all kids to do it. I think it develops regions in the brain that are important. Tinkering leads to a kind of experimental mindset that is important in disciplines like engineering. I also think we should teach the tools we want students to use. Why in the universe would we ask them to waste their time futzing around? All other scientific disciplines teach how to use the tools – remember your chemistry and physics labs? They didn’t just give you a triple beam balance and tell you to play around with it. They taught you what to do with it. Why don’t we do that? There isn’t any value to playing around with a triple beam balance until you finally figure it out, unless it’s to act as a gatekeeper to people who can’t figure out the triple beam balance. We need the doors open wider, not closed off with stupid, irrelevant barriers.
spacemika said,
May 22, 2009 at 5:47 am
I thought about this today when dutifully fulfilling a laboratory instruction to tinker with various filter settings in some image interpretation software. I methodically tried one setting at a time, then in stacks, and concluded that although the results were non-identical, the various filters and equalization had such a minimal impact that my time would be better spent in magnifying the image to hunt for fault lines.
I am a reluctant tinkerer. I need theory, I hate just wacking around and seeing what falls out. With knitting the theory is easy (interlock loops, different methods result in different patterns) so it was easy for me to plan experiments (yarn under the bottom, needles over here, and tug; yarn threaded from behind, needles still here, and pull…) to see the interaction of variables and impact on end results.
…I was going to go somewhere different with that paragraph, but it took me to a simple conclusion: blind tinkering isn’t systematic. Introductory science and engineering training programs are designed to relentlessly pound in a methodical, systematic to approaching problems; laboratory courses emphasize that equipment is both expensive and dangerous so don’t screw with anything without instruction. (Even my departmental stapler has a warning to seek instruction or risk injury & paying for damages.) I call Mixed Messages on scenarios demanding students adhere to strict discipline in all scientific endeavors and meeting tinkering with heavy penalty, yet require that same mucking about for software (and even penalizing its lack).
spacemika said,
May 22, 2009 at 5:48 am
I thought about this today when dutifully fulfilling a laboratory instruction to tinker with various filter settings in some image interpretation software. I methodically tried one setting at a time, then in stacks, and concluded that although the results were non-identical, the various filters and equalization had such a minimal impact that my time would be better spent in magnifying the image to hunt for fault lines.
I am a reluctant tinkerer. I need theory, I hate just wacking around and seeing what falls out. With knitting the theory is easy (interlock loops, different methods result in different patterns) so it was easy for me to plan experiments (yarn under the bottom, needles over here, and tug; yarn threaded from behind, needles still here, and pull…) to see the interaction of variables and impact on end results.
…I was going to go somewhere different with that paragraph, but it took me to a simple conclusion: blind tinkering isn’t systematic. Introductory science and engineering training programs are designed to relentlessly pound in a methodical, systematic to approaching problems; laboratory courses emphasize that equipment is both expensive and dangerous so don’t screw with anything without instruction. (Even my departmental stapler has a warning to seek instruction or risk injury & paying for damages.) I call Mixed Messages on scenarios demanding students adhere to strict discipline in all scientific endeavors and condemning tinkering, yet require that same mucking about for software (and even penalizing its lack).
jdougan said,
July 11, 2009 at 2:25 pm
An interesting perspective. I’ve never thought of the problem as being “not interested in tinkering” but rather “not truly interested or motivated in what they’re doing”. In my world view, tinkering is a byproduct of being sufficiently interested in the area they’re working in. If you are interested you should naturally want to expand your areas of competence and knowledge. Manuals can’t cover everything and teaching how to use the tools, while not a bad thing, won’t help you to find new uses for existing tools.
When reviewed potential hires, I wanted people who would go and explore the solution space and who would keep themselves informed of the possibilities in our fast moving field. Tinkering and ongoing research were two of the markers I used to determine if they were sufficiently motivated. Obviously I also wanted people who would actually do the assigned tasks…but I didn’t want wage slaves either. It’s a balancing act and part of what makes hiring so much of a pain.
Teaching tinkering could be a good idea, but it may just be the equivalent of claiming you’ve warmed up a room by putting a hot water bottle on the thermostat. I think the admonitions that not expanding your knowledge and competence is risky might help a bit, but could backfire as naturally risk-taking people might pay attention.
demark said,
July 26, 2009 at 11:39 am
Hmm, there are all sorts of directions I want to go in with this post. I’ll try and focus on whether tool use should be taught within universities.
Within the unversity, I do think you should be taught the basic use of fundamental tools/techniques such as the debugger. I’m pretty sure I came into university knowing what a debugger is and how to use it, but not everyone might have that. I think it’s only fair to make sure that everyone starts out with a minimum level. I think there could be more room at the more advanced levels to teach or maybe share higher level programming strategies. At lot of the ‘art’ of programming I think really could be shared and disseminated more effectively. Now that I’m out in industry, I do see more coding styles, but as student, there isn’t as much exposure. As for specific tool use though…
Unlike other disciplines, in CS, the risk-to-reward for tinkering with tools is particularly low. The odds of you destroying something is practically nil (backup and/or recompile); the most you risk losing is your time. In addition, throughout your career, the number of tools you will encounter, especially when multiplied with the number of operating environments, is huge.
I think to survive in this discipline it is imperative that you tinker (or at least google), and put some time into learning the new because it’s impossible to expect to be taught how to use every tool/environment combination you will encounter. I personally don’t think that universities should teach tool use beyond the fundamental basics because the likelihood that you will be using a particular tool again is pretty small. I would much rather that the time be spent learning something with more general applicabillity.
Speaking personally, I think I’m less of a tinkerer, and more of a googler. I don’t really see a reason why I should waste time exploring hidden menu options when I can typically find the answer with a few keystrokes.
Tamfang said,
December 3, 2010 at 11:39 am
I like your point about tools. In my amateur programming I’ve been frustrated by not knowing how to use a debugger effectively, or where to look for advice on that.