Be selfish: if it needs to be done someone else can do it

In 2009, in “Girl stuff” in Free Software, I recounted a conversation with Brianna Laugher:

[Brianna] 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 we want to code, or do something else we are currently either bad at or not notably good at, or for that matter which we are good at but in which we’d have competitors, we should consider doing that, rather than automatically looking for and filling the space that is most obviously empty

(See also Brianna’s response.)

Since then, I’ve seen this pattern recur, most recently in some of the discussion around Valerie Aurora’s Advice for women in tech who are tired of talking about women in tech: women who are doing things because, well, the thing needs to be done and no one is doing it, even if what drew them to the job or the project was something else entirely than the chores they’ve ended up with. This is particularly true when the chore has some benefit to others: writing documentation, welcoming newcomers, setting up the translation team, establishing the not for profit and such.

This not only can make women miserable as they find themselves doing a lot of things out of a vague sense of duty, it quite frequently leads to no rewards whatsoever. For others, it’s really nice when the documentation gets written or the notes get taken or the funds get raised without having to figure out how to give someone a promotion or a keynote slot for it, or how to build up a healthy chain of people moving through the task and onto other things! How fortunate for your boss or your project, and how unfortunate for you.

Quite often a good dollop of selfishness is what this situation deserves, and what you deserve too. There is of course a tight limit to which women can or should personally solve the problem of being handed or expected to quietly assume chores and hover around in the background making sure all the wheels are greased, but let’s explore how far you can get, when it’s time to be selfish.

Note throughout this entry that “chores” are very relative. You may not be a natural fit for translating conversations or documents just because you’re fluent in multiple languages! You might want to write some code or do the accounting or answer the phones instead! But this doesn’t mean that documentation or translation are worthless activities that no one should do, just that they’re something that, at this time, and for this project, you want to stop doing.

Figure out what you’re getting out of the chore, and keep doing it.

I’m very often the notetaker in meetings that I’m in. While this is quite gendered (and I’ve occasionally had senior male colleagues notice and call it out, which is appreciated), I do get something out of it. I have trouble paying attention to and understanding conversations I’m present in that I don’t also write up; and, while we’re talking about being selfish, one of the more effective ways to control the agenda is to write it, and one of the ways to control the findings is to write them too.

So, I keep taking notes quite often, but I’m clear on what I’m getting out of it. I don’t take the notes for their own sake, and if I find myself in a situation where I’m losing the ability to participate in or lead a meeting due to being its notetaker, I’m more likely to reconsider whether there need to be notes and if so, whether I need to take them.

But let’s say you’ve thought about it, and you’re not getting something out of the thing, and you want to be done. But the thing is important, it is in some way making the world a better place. If so…

Accept that the project could fail without the chore.

Something to work through is knowing that the chore might be important to the success of the project, and that you’re deciding not to do it anyway.

Maybe the conference will be better with a more diverse lineup and so will the careers of the speakers. If no one sees the notes of the meeting then some important decisions will be missing context. A major security flaw might be hiding in those untriaged bugs.

But if the project’s success seems to depend on you, a single person, quietly stepping in and doing what must be done while everyone else does fun things, the project is either so fragile that it’s at high risk of failure regardless of your exceptional bug triaging and speaker finding skills, or it’s somewhat quietly robust, and will actually carry on just fine.

A related failure mode — “I’m so valuable that my boss won’t let me take vacation” — is something of an Ask a Manager perennial. As she tends to advise: what if you quit? If you quit and your chores are super important, your boss will either find a way to get them done after you leave, or the project will fail, and if it fails in your absence, it probably wasn’t that likely to succeed in your presence either.

So. If you’re the only thing standing between success and failure, you’re not on a great project. It might have great aims or ambitions, but it’s not a great project. So now it’s time to…

Stop doing the thing.

Just don’t do it. Let the bugs go untriaged, the newcomers go unwelcomed, the documentation go untranslated, the meeting go unrecorded, the conference not schedule any unicorn talks, the conference not have any women speakers at all.

While you worked through thoughts about the project failing above, many times, you’ll find that the thing wasn’t that important in the first place. No one much read the notes of that meeting, so maybe there didn’t need to be notes, and in fact, on reflection holding the meeting wasn’t that important either. The conference copped a lot of justified heat on Twitter for their all-male all-white lineup and… probably they deserved it since they were using you to shield them from it before. Speakers of your other fluent language migrated to other software that had a translation team dedicated to their needs, and were better off for it. And so on.

How to just stop:

  • Unsubscribe from the project email list.
  • Block your browser from letting you look at the bug tracker.
  • Delete the request for help finding women for the panel.
  • Read back over your personal notes from the meeting, update your own todo list, but don’t type them up to send to the team.
  • Go on a long holiday.

Give some warning you’re going to stop doing the thing.

If you’re not truly silently labouring away alone, you might want to let people know you’re stopping. That’s fine; but be firm about it, give a date at which you’ll stop, and resist conditioning leaving on another volunteer stepping up. “I’d love someone to take over the server and I’m happy to train you” may work, but it also may not. In embracing selfishness per this post, you need to step down even if no one else is stepping up.

Some scripts:

  • “I’m not available as a volunteer sysadmin after the 1st. I’d love to hand off cleanly to a new sysadmin if possible. However if there’s no volunteers by the 1st, I will shut down the server and provide the data backups to [other person].”
  • “This is the last newsletter from me! If someone else wants to pick it up, here’s a one pager to get you started.”
  • “After some reflection, I’ve decided not to contest the next board election. I’m looking forward to seeing where a new president takes us.”

Ask if you can hand off the thing.

The above two strategies work less well in hierarchical situations like workplaces. If you’ve silently taken on chores or you’re volunteering for things outside your core position you can still use those strategies, but if your boss or another authority figure has told you to do the chore (especially if they told you to recently), probably you shouldn’t just stop and see what happens, let alone send an email unilaterally announcing you’ve decided to stop doing your job from the 1st.

But that doesn’t mean you need to silently do what you’re told at the expense of important work, or do unrewarded tasks while your peers get shiny things. There’s some alternatives you can explore with your workplace:

  • Ask if you can stop: make a case for the chore not being important at all, or not being as important as the other things you need to do
  • Rotate chores: set up a formal rotation of the chore between teams or members of the team
  • Pay someone: pay a bookkeeper for your organisation rather than relying on a series of burned out volunteer treasurers
  • Pay a specialist: hire a project manager or an office admin or a backend dev or a fundraising lead
  • Transition to a more junior staff member: maybe there’s someone who’d learn from writing those docs or triaging those bugs
  • Transition to a team: maybe there’s so many chores that there needs to be a project team addressing the chores and the source of them, and maaaaybe you could lead that team?

That said, in workplaces and other hierarchical organisations, ethical leadership should be avoiding disproportionately handing unrewarding tasks to women, younger people, and members underrepresented minorities, and should be actively considering these solutions themselves. If you’re in a situation where your leadership is happily reaping the rewards of you patiently picking up scutwork unrewarded…

Quit your entire position.

If your current position (paid or volunteer) is full of chores you aren’t rewarded for but that no one can be bothered sharing around or finding someone who’d be a better fit, and you’re fortunate enough to be able to find another position or you don’t need to, quitting is something to seriously consider. Head out the door and selfishly go find somewhere where what they need someone to do is the same thing that you want to be doing.

US tech resistance cheatsheet for Australians

I gave an Australian friend a rundown on my sources of information about US opposition to the incoming Trump administration, focussed on tech workers, and she pointed out that my resources were worth sharing; the “Australian technology worker following US tech industry organising” position is not very common. Here’s my little collection of links:

Tech Solidarity. Tech Solidarity is a series of meetings being run in major US cities for technology industry workers on the subject of solidarity with other workers and with technology users, against an authoritarian Trump regime. There’s a Tech Solidarity website, but the best place to find out about their meetings is their Twitter account, and the best place to find out about their politics is the @Pinboard Twitter account run by Tech Solidarity co-organiser Maciej Cegłowski.

Neveragain.tech. This is a specific pledge by technology industry workers to not be involved in building technology for the US government to target individuals based on race, religion, or national origin, as well as advocating for specific policies in our workplaces and protesting unethical practices. I am a signatory and several of my friends are organisers. A Tech Solidarity meeting was key in launching the pledge.

Indivisible Guide. A guide to influencing members of Congress when your goals are largely defensive and obstructionist, ie, to hinder the dominant party in Congress or the President’s party in implementing their policy platform.

While this guide is interesting, I think considerable caution is called for in applying much of it to Australian politics without asking Australian activists and staffers for their advice. For example, party discipline in Australia is extremely strong — your representatives, if members of a major party, almost invariably vote with that party — and Cabinet and the ministry are appointed from amidst the members rather than separately. The executive being drawn from the legislature is very very different to how the US executive branch works. The chapter on four local advocacy tactics that actually work may have some inspiration for beginning to engage with your state or federal MP’s local activities if you haven’t done so before.

There are several guides to opposing specific Trump administration policies and initiatives, such as Resistance Manual and the re:act newsletter. There must be more of these appearing every day; I’m not following them closely since the calls to action usually require being a constituent of US members of congress and/or being a US resident.

Learning more about a remote working position

I’m in the process of wrapping up a long period of working remotely at least part-time from home, beginning in 2006 when I enrolled in a PhD program and continuing through my time at the Ada Initiative and at Stripe to this year.

My take on working remotely in future is really “it depends on the details” (and likely different details for different organizations). To that end, I contributed some suggested questions you could ask to Hypothesis’s Working remotely guide, which they’ve incorporated in a slightly edited form. Here’s my original questions; I’ve also added a few more at my end after some feedback from Andrew (himself a veteran of around seven years of remote work).

Introduction

Before you start working remotely at a new organization, you should explore how they structure remote working and if there are any expectations mismatches between you and the organization. A particular remote job may or may not be a match for a particular remote worker.

Important: I don’t think there is any one right answer to any of these questions. It’s a question of fit between your working style, the position itself, and the relationship of the position to the rest of the organization. But the answers are worth knowing so that you can evaluate your fit and make plans for effective remote working.

Sources of information

This entry has a lot of questions, too many for a “do you have any questions?” section of an interview. But you can use other sources of information to get most answers, especially about organization-wide questions:

  • the job description, and descriptions of similar roles
  • the organization’s website, particularly the About and Careers pages
  • the section of the employee handbook dealing with remote work
  • the LinkedIn pages or websites of your future manager and colleagues
  • longer, separate, conversations with your recruiter or hiring manager
  • your offer conversation or letter, or your contract

Some questions you also may only need to ask if you hear of concrete plans to make a change to the organization (eg, you learn that a new office is about to open near you).

Questions

How are you remote and who are you remote from? This post is using ‘remote’ to mean something like “most days, you are not in face to face contact with any colleagues.” But you should be aware of the details: will you be working without in person contact with teammates or with the wider organization almost all of the time? Do you have any colleagues in your team or your wider organization in your city or region, or who regularly visit? Will you work on any joint projects with them? Will you be able or be expected to sometimes work with them in person even if there’s not a permanent office space?

Separately, is in-person contact with vendors or customers part of the job?

Is your immediate team remote? Is your manager remote? Being a remote member of a team that is all working remotely from each other is different from a team which is mostly located in an office with each other. Likewise, being managed by someone who is in an office has some potential advantages (for example, access to information circulating through verbal grapevines, being able to access answers from colleagues for you quickly), as does being managed by someone who is themselves remote (a direct appreciation for experiences specific to remote workers, a personal interest in advocating for them).

How many remote workers are there at the rest of the organization? What percentage of teams you will work closely with are working remotely, and what percentage of employees overall are working remotely? Working as one of very few remote workers for an organization where most employees are in an office together is different from a mostly or entirely remote-working organization.

What’s the future of remote work at the organization? If the organization is mostly or entirely remote, are there any plans to change that? If the organization is mostly office-based, are there any plans to change that? If an office is likely to be founded in your city or region soon, will you be able or be expected to work from it?

You may be considering a job on the understanding that the remote work will be of very short duration (eg, an office is opening in your city in two months time). Is there any chance the time will be longer, and are you OK with that?

What is your manager’s approach to remote workers? How frequently will they speak with you and through what media? Will they expect you to travel to them? Will they sometimes travel to you? Have they managed remote workers before?

How long have there been remote workers for? Is the organization new to having remote workers or has it had remote workers for a long time and bedded down a remote working style?

What is the remote working culture like? Is most collaboration over email, text chat, phone, video conf, or some other means? Are there watercooler-equivalents like social IRC channels or video chats? How active are they? Are remote workers mainly working from home or from co-working spaces? Are there occasional team gatherings for remote workers to meet colleagues in person and are they optional or compulsory?

How flexible are the hours? Not all remote work has flexible hours; you may have mandated work hours, or core hours, or shifts, as in any other role.

Are the remote workers spread across multiple timezones? If so, are your team and closest collagues in your timezone or another one? Are you expected to adapt your working hours to overlap better with your colleagues? How are meetings and other commitments scheduled across timezones? Do they rotate through timezones or are they always held in a certain timezone? Are you ever expected to attend meetings well outside your working hours, and if so, how often is this expected and do your colleagues in other timezones face the same expectations?

What are the benefits for remote workers? Will the organization reimburse any of your remote working expenses, such as membership of a co-working space, home office furniture, or your home Internet connection costs? If you’re working in a different country from most of your colleagues, will you get equivalent benefits to your colleagues (eg, health insurance coverage)?

What are the travel expectations for remote workers? Are you expected to travel to headquarters or other offices or customers, and if so, how often and for how long? What are the travel policies and allowances for remote workers? How do these travel expectations compare to those of non-remote colleagues?

Sometimes you will be remote from an organization with an office or even headquarters in the same city as you. Will you be able or expected to visit the office? How often? Will there be resources for you (eg, hot desks, meal provisioning)?

What are the career progression possibilities for remote workers? As a remote worker in a partly non-remote organization, could you move into more senior positions over time, such as team leader, middle manager, or executive? Could you move into other teams in the organization, and if so, which ones? Are there some roles that are closed to remote workers? Match these answers to your own career goals.

What’s the training process like? Must you or can you spend a period of time in an office or visiting a colleague for training? Must you or can you do your training remotely using documentation, videos and similar? Will a trainer or colleague have some time assigned to remotely train you?

Is there support for first-time remote workers? If you haven’t worked remotely before, will the organization support you in learning how to work remotely, and if so, how?

See also

A very partial list of resources, focussing on individual remote workers and their experiences and strategies:

Creative Commons License
Learning more about a remote working position by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Tech interviews, too much homework, and the motherhood question

There’s a fascinating discussion around technical interviews recently; would both candidate experience and hiring signal be improved by revising the current round of (basically Google-inspired) non-runnable algorithm-centric coding examples completed under time pressure?

I’ve been following Thomas Ptacek’s tweets about it for a few months, for example:

Then last week Julia Grace wrote A Walkthrough Guide to Finding an Engineering Job at Slack:

We’ve put a great deal of effort into designing our interview process so that it is comprehensive and consistent, and are working hard to remove as many points of bias as possible. To date we’ve found it successfully identifies people who will succeed here — those with a high degree of technical competence who also embody Slack’s values: empathy, courtesy, craftsmanship, solidarity, playfulness, and thriving[…]

We’d like to get an idea of how you write code in the real world, since we feel this is the best indicator of how you’d write code day to day here at Slack. Granted, the Slack codebase is larger and more complicated than any technical exercise, but we have found the technical exercise to be a good indicator of future performance on the job. There are great engineers at big name companies and at small ones, so this gives everyone a chance to shine independent of where they are now.

This varies by position, but generally you’ll have a week to complete a technical exercise and submit the code and working solution back to us.

Uncritical praise of take home exams started to ring alarm bells for me. I recall take home exams from university; one of my majors was philosophy, which tended to assign a long essay (eg, 4000 words) to be completed over 6 weeks or so, and a take-home exam (eg, 2 essays of 1000–2000 words) to be completed with a four day deadline. I moved out of a rural town to go to university and lived on my own. From age 19, I also financially supported myself. I loathed take home exams, because I was competing with people who would get the exam, go home, and work on it all week in the house they lived in with their parents. No job. No housework. (Admittedly, no self-imposed decision to take 125% of a normal course load every year for four years of university either, that one was on me.)

And that was before I had two children. I’m not at all excited about tech interviews moving to a model where I’m doing a huge amount of work in my own time, because I do not have a huge amount of free time. Anecdotally, I have already heard of people spending in excess of 20 hours on Slack’s coding exercise. Freeing 20 hours in a week is a non-starter for me, especially if I’m not a clear finalist for the job. Slack is administering these take home assignments prior to on-site interviews, and is a very sought after workplace; it’s quite possible their process will be widely copied and people will regularly be doing a couple of days of coding before in-person interviews, for many many jobs.

To be fair, I have also read through Steve Yegge’s Get that job at Google and estimate that, at my current levels of free time, it would probably take me a couple of years to complete the preparation he recommends. (I have an undergraduate degree in computer science and mathematics — the philosophy major was a separate degree — and a PhD in computing, but at this distance I am far from passing an exam in discrete maths.) But I also wouldn’t be required to submit work samples proving I’d spent that time.

I am also aware that other positions require extensive preparatory work for job interviews for senior candidates, such as preparing sample budgets or strategy presentations or similar, but it’s at least more common only to give such large amounts of work to later-stage candidates for the position.

Let’s not get uncritically excited about adding (yet another!) screen for “isn’t a mother of young children”. I am thrilled that Camille Fournier has made several similar points in Thoughts on Take Home Interviews (also available on her blog):

On twitter, a discussion ensued about whether asking people to spend time at home doing exercises didn’t itself cause bias, against those who did not have a lot of spare time to be doing take-home exercises. Julia mentioned that they expect it to take 2–4 hours, but admitted that some people got really into the project and spent far longer than that[…]

The creative take-home also seems likely to select for those with free time, because if it is really an exercise that some people want to overdo, they will overdo it and you will have a hard time not rewarding that enthusiasm (why shouldn’t you!). And while it’s ok to ask for a few hours, building something that rewards those who can spend far longer is likely to bias against those who have, say, kids to take care of after work and on weekends, or other activities that limit their free time.

Gaëtan Voyer-Perraul also notes in a reply:

If this thing catches on, then it’s going to become a gating mechanism for every developer job in existence. New grads will be faced with hundreds of hours of “take-home” work that goes into the same black hole as their resumés.

Also worth a read: Rod Begbie gives a postmortem of a take-home interview question he used to administer.

I’m excited about revising the technical interviewing process, which will require both experimentation and evidence. While experimenting, and as the tech industry actively seeks candidates from under-represented backgrounds, the ability of candidates to interview with your organisation without tens of hours of free time for take-homes in addition to time for on-site interviews should be a core design principle for your interview process.

Remembering Telsa Gwynne

Telsa Gwynne, whom I knew through my time in the LinuxChix community between 2000 and around 2007, died this week:

Telsa is the direct inspiration for the entire 15 years of content on this website, especially the personal diary. Before joining LinuxChix, I first knew Telsa through her online diary (its archival title, “This was a diary, once”, is painful to read now), which I heard about through someone who read Alan Cox’s diary, and I was struck by how striking daily life could be in written form. Telsa’s diary was full of personality and snark, and singlehandedly inspired me to begin writing about my life online too.

I thought of her as a net celebrity, although not in the usual way of “married to Alan Cox”, but as “writer of one of my favourite websites”. I was therefore a little bit shy about directly interacting with her when I initially joined the LinuxChix lists in 2000, but I first met her in person in 2001 at linux.conf.au when she and Malcolm Tredinnick were hanging around debriefing and complaining about CVS, on which he was teaching a tutorial that year which Telsa later wrote up. She was grumpy and kind and normal, even if she did know CVS.

Andrew saw her again at LCA in 2003, but I didn’t go and I think I only met her one more time, in Wales in 2004 when we visited their house and due to poor planning with trains, ended up staying the night. Telsa and Alan were kind hosts and we enjoyed Telsa’s huge knowledge of local history as we walked all around Swansea.

Telsa’s final diary entry in 2006 says she “plain[ly] and simpl[y] los[t] interest in running to stand still just to understand how to use anything mechanical.” However hard she worked for it, I remember her as profoundly technically knowledgeable and an excellent teacher. A great deal of my initial learning about both CSS and character encodings came from her, and she was well known as a high level user of DocBook. A friend shared one of her posts to a private LinuxChix technical list today, walking through the differences between library packages and -devel packages in Linux distributions, and their implications for compiling software.

I hadn’t been in contact with Telsa since she or I variously withdrew from our common online communities, so since 2007 or before. I kept an eye on the very occasional updates to her website, and was pleased to think that she had found a more satisfying life outside her Free Software community volunteering. I still find this a happy thought.

Telsa was also a critical inspiration to me as an activist: in the early 2000s (and still) it was hugely controversial to either believe that open source communities could still work if they were more civil (the entire LinuxChix project was partly an experiment with that), and even more so to insist that they should be. Telsa is the earliest person I can think of who stood up in an open source development community and asked it to change its norms in the direction of civility. I don’t know how heavily her online harassment experiences played a part in her departing Free Software and some online communities — I hope it wasn’t a large part — but I’m sorry it happened and I’m angry.

Telsa was a brilliant and kind and strong person, and I am sorrier than I can say that we will never be in contact again. To Alan, Debbie and others who loved her: my profound sympathies for the loss of an amazing person.

Other memorials:

Telsa online:

Creative Commons License
Remembering Telsa Gwynne by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Quick hit: Google publishes their EEO-1 diversity data

This article originally appeared on Geek Feminism.

As promised earlier this month, Google’s diversity data is now up on their blog.

They write:

We’ve always been reluctant to publish numbers about the diversity of our workforce at Google. We now realize we were wrong, and that it’s time to be candid about the issues. Put simply, Google is not where we want to be when it comes to diversity, and it’s hard to address these kinds of challenges if you’re not prepared to discuss them openly, and with the facts.

Their numbers — globally — are 70% male, 30% female (this seems to add up to 100%, which suggests that either Google or the EEO-1 process need to review their gender categories), dropping to 17% female among their technical employees. We’ve tabulated some data at the Geek Feminism wiki. You can compare with female-male breakdowns from some other companies (many quite small) at We Can Do Better.

Google’s US workforce is also 2% Black, way below US national figures of 13% nationwide and 3% Hispanic against 17% nationwide. (Nationwide figures from US Census numbers dated from 2012 and rounded to the nearest whole number to have the same precision as the Google figures.)

What do you think? Is disclosure a meaningful action here? Are you surprised by Google’s figures? Do you think the rest of the tech industry will or should follow?

Remembering Malcolm Tredinnick

I flew home from the US yesterday and when I arrived in Sydney I got a message from my husband saying that Malcolm Tredinnick had died. According to this piece by Simon Dulhunty, he was found on Monday to died at home in Sydney, possibly after a seizure, while I was at PyCon 2013.

Malcolm Tredinnick speaking to an audience
Malcolm Tredinnick speaking at DjangoCon 2008 (by Sebastian Hilling CC BY-NC)

I’ve known Malcolm slightly since my first linux.conf.au in Sydney 2001. In late 2004 I interviewed for a job at CommSecure (since closed) where he was then working, having been a lead developer of and continuing to maintain and develop a real-time data delivery system for the Hong Kong stock exchange. (The eventual end of that contract was the reason CommSecure later closed.) He was also my boss for about half of 2005 until I left to begin my PhD in early 2006.

I still caught up with him at technical events, the last long conversation I remember with him was at PyCon AU 2011 where my husband Andrew and I had a very Malcolm conversation with Malcolm, which roved over the paperwork hassles of having no fixed address (Malcolm travelled a lot and went through periods where he housesat or lived in serviced apartments for a while), the Australasian chess community, and some gentle mutual trolling between him and Andrew over narrative testing.

What I will remember most about Malcolm is that he was a teacher at heart. I never personally had this relationship with him, but I knew several people at CommSecure and elsewhere who Malcolm had tutored or mentored in programming, often over a very long period of time. Elsewhere I know he had taught mathematics (long before I knew him, he very nearly completed a PhD in mathematics when his area suddenly became fashionable and about 50 years of work was done in 6 months by incoming mathematicians) and chess. I will also remember his dry and sadonic approach to nearly everything (for a very recent example, Malcolm gives useful parenting advice), combined with “really, how hard could it be?” used both straightforwardly and distinctly otherwise. Goodbye Malcolm.

Update, funeral plans: Ray Loyzaga who was Malcolm’s close friend, and long-time founder-CEO of CommSecure, has announced that Malcolm’s funeral will be at 2:30pm Thursday April 4, at Camellia Chapel, Macquarie Park Cemetary, North Ryde, Sydney.

Other memorials:

Malcolm online:

Creative Commons License
Remembering Malcolm Tredinnick by Mary Gardiner is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Fun at LCA 2013: my picks for Thursday and Friday

Thursday

I rarely go to LCA’s tutorials, but really, after years of not having to worry too much about distributed version control systems due to having in-house technical support from my husband, a (now former) Bazaar developer, it’s probably time that I came to grips with git. Hence Git For Ages 4 And Up (Michael Schwern) is tempting, hopefully it’s OK for those of us who do use terms like “directed acyclic graph”. This does mean missing Wiggle while you work (Neil Brown) though: apparently you can’t be a git beginner whilst being interested in newfangled patching algorithms.

After lunch The IPocalypse – 20 months later (Geoff Huston) calls to me: it’s the sequel to his LCA 2011 keynote, which is the one that stood out to me. (Well, and Mark Pesce’s, yes, but funnily enough his actual content largely passed me by.) All that doom and gloom, and now what? Has IPv6 cost us our Internet?

A Tridge talk (Building a free software telemetry radio system) is an even more obvious pick than a Matthew Wilcox talk. (Although why did we put that particular talk up against Buffer Bloat? Tridge is going to talk about TCP performance issues.)

In the afternoon Keith Packard has a new passion (Teaching Robotics and Embedded Computing with Legos and Arduino) and then Ristretto: run-time types for JavaScript (Shane Stephens) sounds alarming. In a good way.

Friday

It might also be a two-tute LCA, with Beyond Alt Text: What Every Project Should Know About Accessibility (Denise Paolucci) up first. BUT NovaProva, or How I Did Six Impossible Things Before LCA (Gregory Banks) is the good crack (“NovaProva implements true reflection in C/C++”???), so… difficult!

After lunch, Asheesh Laroia’s Quantitative community management is closer to what I do but I am also curious about The real story behind Wayland and X (Daniel Stone). In the final session, probably Building Persona: federated and privacy-sensitive identity for the Web depending on how my conference energy is going.

And then where?

I’m headed back to the USA in March for PyCon, and I’m looking forward to having way (waaaaaay) less commitments than I did at Wikimania 2012, and therefore being able to catch more of the talks. And not dragging myself to my hotel room at 4pm to order crème brûlée room service because I am too tired to figure out how to work the lifts. (It was good crème brûlée though!) The Ada Initiative will probably be running some non-talk activities though, so it won’t be wall-to-wall talks. And then a second return to the USA for AdaCamp SF. And that really might be enough for one year, but if not, there’s always Kiwicon.

Fun at LCA 2013: my picks for Tuesday and Wednesday

I’m currently regarding LCA 2013 as my last LCA for a while. Never say never: LCA 2014 bids came in from Sydney (so, local to me) and Perth (where I’ve never been and would like to go). But I first went to LCA in 2001 and then later went to 2004 and since 2007 I’ve been to LCA every year, except for 2010 and that only because I had a baby in the middle of the conference.

LCA used to be my main way of reconnecting with open source while I was working on my PhD. But now I work for the Ada Initiative and open source (and open stuff) events are a big part of my job. While I have more time and energy for conferences I am attending them for very different reasons now and the lure of the new is getting strong.

Because my volunteer time is diminishing, LCA 2013 is definitely the last LCA in which I will have had significant input into the program (Michael Davies and I are co-chairs of the conference program this year, as we were for 2010). So, it’s something of a farewell tour for me and I’m looking forward to the program we worked so hard putting together.

Monday

… actually my non-LCA-ing family is still in town Monday, so I’ll probably go to Bdale Garbee’s keynote and then hang out with them. Off to a great start here, I know.

Tuesday

Radia Perlman’s keynote is the keynote I am most looking forward to this year. Following that several of my peeps are giving Haecksen talks before lunch:

  • Feminism, anarchism and FOSS – Skye Croeser
  • Overcoming imposter syndrome – Denise Paolucci
  • Security – Joh Pirie-Clarke

People may be especially interested in the Imposter Syndrome talk, Imposter Syndrome being the feeling that you’ve achieved your current position or status totally fraudulently and are going to be discovered any second and publicly humiliated. It’s very common among people who are in quite critical fields (like academia). Denise was among our Imposter Syndrome facilitators for AdaCamp DC.

I am not sure after lunch, but Web Animations: unifying CSS Transitions, CSS Animations, and SVG (Shane Stephens) is a definite contender. In the afternoon The Horrible History of Web Development (Daniel Nadasi) sounds interesting (although it’s the kind of talk where an abstract would be really useful in determining whether I want to go) but so do What we can learn from Erlang (Tim McNamara) and Concurrent Programming is not so difficult (Daniel Bryan)

Wednesday
Trinity: A Linux kernel fuzz tester (and then some) (Dave Jones) is very tempting in the first slot, but I think I will go to Think, Create & Critique Design (Andy Fitzsimon) because I want to “speak” design semiotics a little bit better and have for a long time. Talking to graphic designers is actually part of my job.

In the second slot I am not entirely sure, but probably Open Source and Open Data for Humanitarian Response with OpenStreetMap (Kate Chapman) since I periodically dabble in OpenStreetMap.

After lunch my pick is definitely Free and open source software and activism (Sky Croeser). I’ve been following Sky’s activism and research since the EFA lamb roast fun and met her at AdaCamp Melbourne. I want to hear what she has to say about (h)ac(k)tavism.

Not as sure about the following slot (in a moment of mischief, we put the DSD’s talk right after Sky’s, but I’m not especially interested) but the biggest contender is The future of non-volatile memory (Matthew Wilcox) because he usually is one of the highlights of the LCA lower-level technical talks.

The first slot after afternoon tea I am not committing, but it does contain Pia’s grand scheme Geeks rule over kings – the Distributed Democracy. After that I think Copyright’s Dark Clouds: Optus v NRL (Ben Powell) is required: it isn’t LCA without emerging feeling distinctly gloomy about the current state of the intellectual property framework.

2012: resume fodder

Because I had quite a difficult year in several respects, especially health-wise, some short notes on my 2012 accomplishments.

Total eclipse, partially obscured by cloud
by Flickr user 130GT

Ran AdaCamp. AdaCamp is really originally my baby and AdaCamp Melbourne was significantly my work (with Val, and Skud as local organiser). AdaCamp DC was significantly less so (because I was on study leave between March and May), but still, even on the day they’re a lot of work.

Delivered three talks at linux.conf.au. We gave an Ada Initiative update and an allies workshop at the Haecksen miniconf and our Women in open technology and culture worldwide talk at the conference proper.

Submitted PhD thesis. This was, of course, the end of a huge project. I enrolled in March 2006 and was full-time until December 2009. I was then enrolled part-time from July 2010 (after maternity leave) until May 2012 when I submitted the thesis. The submitted version is 201 pages long, word count is difficult with LaTeX.

Delivered the keynote address at Wikimania. This is to date my largest ever audience, I think.

Saw a total solar eclipse. Less of the work, just as much reward. The photograph of the eclipse shown here isn’t mine, and isn’t exactly like our view (we saw the top rather than the bottom through our bank of cloud) but it’s also from Port Douglas, and is very similar.