Plans for 2010

I don’t intend to write much about my just announced pregnancy over on the thoughts/geeky side of my weblog, but there are a couple of geek implications, assuming all goes well:

  • it’s unlikely in the extreme that I will make it to OSDC 2009 in Brisbane in November (it’s very close to the deadline when airlines will stop letting me fly, in addition to discomfort and so on); and
  • it’s completely impossible that either Andrew or I will make it to linux.conf.au 2010 in Wellington in January.

I’ll not be especially available for additional volunteer tasks in 2009, since I will be trying to finish my PhD work with a small human trapped in my abdomen.

For Andrew’s other 2009 and 2010 availability check with him, I can’t see that I’ll be volunteering to travel before at least April 2010 and that might depend on someone donating a nanny to accompany me.

I am cut about lca2010, especially considering the effort I’m sinking into it. I really hoped that wouldn’t happen, but it’s turned out to have the worst possible timing. If a generous donor offers to fly, say, 20 of the speakers to Sydney afterwards and re-stage the conference for the sole benefit of me, I will not say no.

Possible structures for a technical talk

Edited version of a private email I sent about linux.conf.au 2010 preparation, but not conference-specific. The email discussion led to me enumerating the kind of talks that I think you can give about technical subjects at a linux-conf.au-style (non-academic developer-oriented) conference.

Recitation of facts; or the architecture diagram talk

In this kind of talk, the speaker walks the audience through, say, the architecture of a project. The talk contents are dictated by the architecture. Five minutes on the input module, five minutes on preprocessing, five minutes on transforming into a new set of matrix bases, five minutes on postprocessing, five minutes on sanity checking, five minutes on rendering.

This is the most obvious structure for a technical talk. It’s also the driest structure. It is useful mostly for audience members who want to work on or with the project code, which is for most talks a small fraction of the audience. It best suits very major projects with years of cruft in their architecture and a wide potential userbase.

Insane hack adventure; or "hacking the Tivo", Andrew Tridgell, linux.conf.au 2001

In this kind of talk, the speaker usually talks about a project he or she personally undertook and structures it as a battle against the odds. So of course Y is the most obvious solution, although not trivial. So I tried Y for a couple of months. And then it turns out that the X protocol absolutely makes Y impossible for these reasons [dramatic pause] and at this point any normal human being would have given up, but I retired to a monastery for six months and returned refreshed and a lotus blossom I saw on my return inspired me to try Q…

This is probably the most effective structure for a technical talk and it’s surprisingly widely applicable (you can frame a lot of things in terms of here’s the current problem, here’s what you think the obvious solution is, here’s what happened when I tried it). The biggest limitation is that it’s very hard to do it about work you didn’t do yourself so it’s not available to all speakers. And you can misjudge it: so of course I tried Y says the speaker uh, Y is obviously dumb, why didn’t you go straight to Q? asks the audience (at some conferences, they might well ask it out loud, repeatedly). It doesn’t work for speakers who don’t have expertise (at least narrowly on this one topic) over that the audience has.

Demonstration of surprising ease

In this talk, the speaker proposes a task which sounds too formidable to complete in the talk slot. (Pretty much any task, for some talk slots.) They then proceed to show how it can be done despite the odds using their tool. Edward Hervey edited a video PiTiVi at linux.conf.au 2008. At OSDC 2008 Thomas Lee added a ‘unless’ keyword to the Python language.

This structure can be fun but it has a lot of pitfalls. Edward was continually battling to type while dealing with a handheld microphone. Speakers should recruit an assistant for these talks. The Python keyword talk was kind of fun, but it was also hard to follow: and now I am going over to this totally other tree and adding several lines to this other file at line 1099 and 1346 and is obviously required: he did not succeed in making me think I could easily edit the Python language. In all cases, it needs a decent amount of rehearsal: even more so than other talks.

Dropping of wisdoms

These talks are generally (at linux.conf.au anyway) talks about the social/community/artful aspects of coding. For example, Jonathan Corbet’s talk about how kernel hacking actually works in terms of the trees and maintainers etc at 2009. (One of Linus Torvalds’s bigger 2009 contributions was being in the audience for that talk and adding occasional commentary on his various prejudices.) Andrew Bennetts has had some good luck with a series of talks that began at OSDC 2008, in which he essentially lists every tool he can think of to help you make your Python programs faster. I didn’t see it but I would guess Paul Fenwick’s talk about awesome things you’ve never heard of in Perl was the linux.conf.au equivalent in 2009.

These are useful talks, the main pitfall is that they require considerable expertise over the bulk of the audience. Otherwise someone is just listing a bunch of stuff you do every day back to you. They also need to be about tasks or tools that a lot of people actually use or want to use. No one wants the hidden tricks to using libnousersexceptme.

On girl stuff

In both of my recent talks involving women and Free Software the audience has latched onto something I didn’t expect. At OSDC it was the GNOME finding that they only got women applying for their summer of code projects once they created special ones for women. I think I expected people to have heard about that already, but they hadn’t. (GNOME had zero applications from women for Google Summer of Code, and some hundreds for the Women’s Summer Outreach variant.) There were probably a couple of things going on there aside from women responding to a specific invitation — in particular, computer science academics at some universities getting excited about being able to give their women students a specific invitation — but clearly invitations are part of what’s going on.

There is a karmic debt to do some work already incurred by giving these talks, but since the work I do isn’t Free Software and wouldn’t be generally useful if I released it as such (I know a lot of people say this about their work, but I try and predict word usage based on the opinion of the document, this really is quite niche software) and I had a reasonable idea for a variant on this kind of talk, I gave a second one anyway, at the LinuxChix miniconf. It was titled ‘Starting Your Free Software Adventure’ and happened to use women as examples. The idea was to show people what the first steps look like. I conducted (extremely short) interviews of several women involved in Free Software or Culture or their communities, including Kristen Carlson Accardi, Brenda Wallace and Terri Oda among others. (I intend to make the slides available, but since I quoted the subjects extensively and directly, it will require gathering permission and then a bit of work editing them.)

As I noted previously this talk was a failure all up, because the wrong audience turned up for it. But one thing stood out and kept coming up all week: Terri mentioning that she had resisted at times working on things perceived as ‘girl stuff’. In Free Software this includes but is not limited to documentation, usability research, community management and (somewhat unusually) sometimes management in general. The audience immediately hit on it, and it swirled around me all week.

This is a perennial problem for professional women: software development is by no means unique in having developed a hierarchy that goes from high status roles disproportionately occupied by and associated with men to somewhat lower status roles disproportionately occupied by and associated with women. (In the case of software, disproportionately occupied by women still means male dominated, by the way, at least in the English-speaking world.) It’s difficult to disentangle the extent to which women and/or their mentors and teachers self-select for the lower status roles (and I would hardly argue that the self-selection occurs in a vacuum either) versus the extent to which they are more or less barred from high status roles versus the extent to which the association is actually flipped and professions and jobs within them have become low status because women started doing them. Other well-known examples, are, for example, the concentration of women in biological sciences as opposed to, say, physics, the different specialisation choices of male and female medical doctors and surgeons, and so on. Sometimes, as in the war between sciences, the status of a field is somewhere between a joke and real, to the extent that those can be differentiated, but often it isn’t: there’s a correlation between the male to female ratio of a medical specialty and its pay.

In all of these cases, a woman who is conscious of this problem tends to face a choice. Do the ‘girl stuff’, or not? (Of course, ideally one rejects the dichotomy, but no individual woman is responsible for constructing it, and if you are sincerely of the belief that one is not programmed to a frightening and unavoidable extent by one’s social context we’re working from very different premises and don’t have a lot to say to each other.) And some, although I don’t know what proportion, of women feel guilty about their choice, especially if they do choose to do girl stuff. Just go ahead and imagine your own scare quotes from now on, by the way.

It also gets messy in various other ways. There’s the extent to which a woman who doesn’t do girl stuff is invested in maintaining the status she has chosen and also the aforementioned loop where if women are doing something, it will come to be seen as not particularly hard or noteworthy.

Most concretely, I usually see this tension bubble away underneath outreach programmes promoting computing careers (you know what, I have my own status issues and I still resist calling it IT) to women. There’s the people who want to go for yeah we all know coding is populated by weirdos, and male weirdos at that, luckily you don’t have to be a geek and you don’t have to code, phew! I tend to hear about that one only once my outreach friends have gotten involved and staged a coup, admittedly. There’s the there’s so many opportunities in computing, and yes, coding is one of them and its fulfilling and it’s something you can do, but dammit, coders get all the cred and attention and dammit can we talk about something else? Women who admin/write/test/manage rock! And there’s you know, women coders don’t exactly rule the world yet, and furthermore isn’t all this oh-yes-you-could-code-I-guess-and-that’s-a-fine-thing but look! something for folks with people skills! talk basically a soft version of ew coding that’s for boys, also, last I checked, math is hard?

I observe again that there’s no right answer here in the real world right now. Women doing girl stuff have good reasons to feel dissatisfied that their hard-won skills are underpaid and under-respected, women doing boy stuff (scare quotes! please insert!) want other women to know that there’s fun to be had over here, thank you.

One crucial point in my thoughts about this I stumbled on only after the conversation Brianna Laugher recounts, over Indian on the Friday night (the location of all major conference breakthroughs worldwide). She said — paraphrased — that she didn’t feel that she should have a problem or be criticised for doing what she is good at, or what’s so desperately needed in her communities, and have to be just another coder in order to be fully respected. And I said that while this was certainly true, women also need to have the opportunity, to give themselves the opportunity, to be selfish: if they want to code, or do something else they are currently either bad at or not notably good at, or for that matter which they are good at but in which they’d have competitors, they should consider doing that, rather than automatically looking for and filling the space that is most obviously empty.

I had a brief, but related conversation with Jeff Waugh at the Professional Delegates Networking Session — an attempt to formally recreate the Indian diner breakthrough environment —  at which he commented that he continued to find the invitation culture (the same one I discussed in my OSDC talk) of women in Free Software mystifying and frustrating. (Not his exact words, if you have better adjectives Jeff let me know.) I took that one somewhere else: specifically to invitation cultures outside Anglo culture and then to honorific use in the Korean language, but when considering the question of women I think this is intertwined with the be selfish thing: women are reluctant to enter places where they aren’t obviously welcomed, and what better way to be welcomed than to do work that needs doing and not become just another person doing the coding free-for-all and delaying external validation for potentially quite a long time?

I have no answers. Just the perennial question of distinguishing what other people want, what other people claim they want, the genuine satisfaction of being of service to someone, and the genuine satisfaction of knowing you’ve done a good job of something hard. Take a look at where you’re standing on that one occasionally.

Logging into the OSDC wireless network

I have a wireless login script for attendees of OSDC who use Ubuntu, Debian, or anything else that can run scripts on connecting to a network and has essentially the same iwconfig output:

 eth1      IEEE 802.11g  ESSID:"Monash-Conference-Net" Mode:Managed  Frequency:2.437 GHz  Access Point: 00:13:7F:9D:36:C0 

To save some tiny amount of time when connecting to the wireless, stick my osdc-login script in your /etc/network/if-up.d directory or equivalent and give it similar permissions to what’s already in there. You can get the latest version of the script at https://gitlab.com/puzzlement/osdc-2006-monash-wireless-login/raw/master/osdc-login, or through Bazaar git, with the repository at https://gitlab.com/puzzlement/osdc-2006-monash-wireless-login/tree/master. It’s very small, but feel free to send me improvements (although if using Bazaar git, please don’t check in a version containing the real username and password).

You need to replace INSERTCONFERENCELOGINHERE with the appropriate username and INSERTCONFERENCEPWHERE with the password. By running the script you will be agreeing to Monash’s terms of service, which are here.