Category: Opinion

My thoughts on a particular topic. May or may not be helpful to others

Posted on

Improving Speaker Diversity

Last month at Devoxx I was in a session discussing what we can do to encourage more diversity in our speakers (specifically, although not limited to, increasing the number of women speakers).

I’m going to outline the things I remember being discussed, although as usual we did not find the answer to the problem, only identify some issues and explore some options.

This is a very chaotic blog post, because if I don’t post it now I’ll never post it, and it’s better if my thoughts are scrawled down and posted than if this all goes to die in my drafts folder.

Firstly, what stops people from stepping up to speak?

I don’t have anything to say
This is the very first thing any developer says when you ask them why they haven’t thought about presenting at conferences or user groups. Turns out, you always have something to say. For example, our most popular sessions at the Sevilla JUG and MUG are “Introduction to…". You hear from plenty of experts who have travelled the whole road to some pinnacle of excellence, but what many developers need is simply someone a couple of steps ahead of them to lead them forwards.

You always know more than someone, you don’t need to know everything, and you don’t need to know more than everyone

Why should I be role model?
So many women feel this, and I’m completely sympathetic to this view point: I’m a woman developer, getting along, happy in my job, happy being a programmer, why the hell should I have to stand up and present and blog and be a role model for other women? Men don’t have to do that. Men can just be developers.

In addition, there’s the fear that if you do stand up, become a role model, that somehow people will think you’re representing all women developers. You’ll be worried because you can only represent who you are, what you do, you can’t represent a whole gender in a single presentation or a single interview. And the pressure! What if I mess up? What if I say something my gender does not agree with? What if I say something that causes my whole gender to be judged?

Totally understandable fears. Totally true that many people will ask you to be the woman developer, to answer for all women. Well, that’s why I’m asking more women to stand up, to be role models - if we all step up, it will no longer just be me, and you, and that other one over there. There’ll be more of us, more differing voices, we’ll stand out less. But we have to stand up first. And in the meantime it’s us and our points of view they’re listening to. Wouldn’t you rather voice your opinion than have someone else speak on your behalf? Especially when very few people really can represent you, who you are and what you want.

What if I can’t answer the questions?
You’ll be surprised at what you do know, so people who present run into this less than you’d think, even if you’re just beginning, but just in case here are some tips:

  • Repeat the question, paraphrasing. Firstly, this ensures you’ve actually heard the question correctly. Secondly, it allows the whole audience to hear it, and thirdly, but most importantly, it buys you time to think.
  • Be honest - say you don’t know, and move on. If you know somewhere that might have the answer, point the person to that resource. But a technical audience actually values the answer “I don’t know” more than you think. Especially the person who asked the question, it makes them feel really smart!
  • If you don’t know, but you think the audience might know, throw it back to them. Either to the person who asked the question, if that feels appropriate (especially if this is one of those “look how smart I am” questions), or to the audience as a whole. In conferences in particular, there’s a good chance someone there knows the answer.
  • If you’re genuinely terrified of all questions, say at the start of the presentation that you won’t take questions in the talk. Offer an alternative, like via Twitter or e-mail, if you can.

What can conference organisers do?

Specifically invite the people you want presenting
Don’t just wait for them to submit. If you want more women, more diversity, invite them. And invite them early…

Secure your women presenters early.
Recognise that there are relatively few women presenters on “the circuit”, and understand that everyone wants them to speak at their conference. This rare breed, the female technical presenter, gets booked up well in advance. They’re probably as in-demand as your keynote speakers, and can probably devote less time to appearing at conferences than those who have made it to keynote-standard (I’m making a sweeping generalisation that your techy women have day-jobs as developers and your keynote speakers are either professional presenters or at least can argue presenting as a critical part of their job).

So, you have a limited resource (experienced women presenters) that’s in high demand. You need to reach out directly to them, invite them, and secure them well in advance of your conference. Many big conferences, for example JavaOne and QCon, will invite speakers six months in advance. If you give women speakers a month’s notice before your conference or event, they simply are not going to have the space in their schedule at that late notice.

Showcase your diversity on your website
If you haven’t already heard of microaggressions, go and read what that means before you get any further. There’s a very simple thing you need to do with your website, whether you’ve opened for CFP or you’re trying to get attendees to register - make sure the photos on your website show the type of diversity you want to encourage. Only yesterday I was looking at the website of a big conference, who I know for a fact are working really hard to ensure diversity, not just with gender but race, age, and where possible in less physically obvious dimensions. The conference is many months off, so the only photo they have on the website is a background photo of the exhibition hall from some previous year, crammed full of attendees - white, male attendees, as far as it’s possible to tell. It’s extremely subtle. You might not even notice, as the photo is behind the headers and text of the site. But I noticed. And you can be sure the subconscious of every person who went to the website to either submit a proposal for a talk, or is considering asking their employer to pay for the registration, also noticed. The conscious mind might be able to shrug it off. But the subconscious of a non-white and/or non-male person notices and plants the subtle seed of “this conference is not for me”.

So, conference and event organisers - if you want more women applying to speak at your conference, show more women on your website. If you want a more diverse audience, show more diverse faces. If you’ve invited your women presenters early and secured them early, show their photos on the site - this sends a strong message to other women that their talk proposals will be taken seriously.

Run warm up nights to try out new speakers
I know conference organisers get lots of submissions, and I know it’s hard to tell which are going to be good speakers, especially if they’re new speakers or don’t have a video. If you’re genuine about improving the diversity of your speakers, run free nights to a) promote your conference and b) try out new speakers. Probably a good idea to have a new speaker and a known speaker to attract the crowd and give newbies a chance.

Don’t be so damn picky

  • New speakers need to be encouraged. Find a way to see their content without just discarding an unknown name.
  • Existing speakers might not have the luxury of creating new content. Many conferences want genuine practitioners, not just evangelists, but those people have day jobs and can’t be creating a new talk just for your conference.

Leave space for new speakers
…and don’t just have 7 slots for a pro speaker

Look at your swag
Not just guys t-shirts. One conference gave out cupcakes for example. But it doesn’t just have to be handbags and high-heeled shoes, just take a quick look and see if your swag is generally useful for techies, or if it leans towards men only. Men only swag (men’s t-shirts, bottle openers, subtle things like that) subliminally says “you don’t belong here” to the women.

Give feedback
You can’t tell every individual why they were rejected, but you could look at all the rejected submissions and give broad indications of the type of CFPs that didn’t make it. Maybe write a blog post explaining which sorts of talks didn’t make it and why. This will help speakers create content that better fits your conference.

Be specific about what you’re looking for
If you have tracks you’re finding content for, put them on the website/CFP, so people know what the topics are. If you have an idea that you want 30% beginner material and 30% very advanced, make that clear too. Especially if you want only beginner or only advanced. People will submit more appropriate talks.

Have a beginner’s track
…not just for the speakers, for the content too. Beginner speakers may be more comfortable presenting “Introduction to…” talks.
Having a beginners track, whether it’s for content or speakers, will make newbies feel more included.

What other things can we try?

User groups can grow talent

  • Practice writing CFPs
  • Help each other
  • Presentation skills
  • Lightning talks, book club, different meetup styles (like fishbowl)
  • Run an open conference to encourage new speakers

Women’s user groups are instrumental
So here’s something interesting. I’m sceptical of all-women user groups as I feel it separates us from the communities we should be contributing to. But women’s user groups can help us to integrate better. For example, Duchess France helped and encouraged its members to submit talks to Devoxx, gave feedback on CFPs before they were submitted, and provided a safe place for the women to practice presenting beforehand. I think this is exactly the sort of thing women’s user groups could be fantastic for.

Advice for budding speakers

  • Just Do It
  • The more you do it, the more comfortable you’ll be
  • If you’re a speaker, it can make you feel less of an impostor at a conference - you’re not just a woman developer, you’re a speaker!
  • Everyone’s afraid, it’s not just you
  • Every developer wants to learn
  • The audience is on your side
  • Start Small (user groups)
  • Be technical. But you don’t have to be super smart
  • Bootstrapping is hard - you haven’t presented so you can’t get into conferences. Again, user groups can help with this.
  • Pair. Ask a more experienced presenter if you can co-present with them.
  • Ask for mentors
  • Ask for feedback
  • “I don’t know” is perfectly acceptable.

I appreciate there is so much more I could have covered, and many topics deserve more depth. But this is the brain dump from the Devoxx session, and maybe one day things will be expanded into their own topics.

Posted on

The Handover

Yesterday I walked into the kitchen to see how lunch was going and my boyfriend handed me a knife, a part-chopped hard boiled egg and said "finish this, I need to have a shower". As you do. Apparently there were two things that needed doing - "this" needed finishing, and I needed to keep an eye on the fish.

Fine.

Continue reading "The Handover"

Posted on

Kids These Days

I'm a great believer in getting kids to code early - after all, I'm of that generation that was taught

10 PRINT "HELLO"
20 GOTO 10

at the age of 9. There are quite a few approaches to teaching today's kids in an engaging way, but I'm a bit wary of the sandbox solutions that teach kids things like how to navigate a virtual thingie around the screen, or lets them create things in a limited virtual world. I don't think kids will easily make the leap between these sort of games to seeing the full potential of programming - they're too limited and have no context for the kids. It's just another game.

Kids need to understand how programming fits into their world, they need to understand the context of coding, if they're going to fall in love with it.

Continue reading "Kids These Days"

Posted on

Developers hate support, don’t they?

I'm at the end of my first official week doing support for 10gen. My major achievements are:

  • Learning how to work the coffee machine in the Dublin office. It's taken me a week to get it, but now I can understand the machine's needs. Even if my coffee did taste a bit of cleaning fluid this morning.
  • Navigating around Dublin - I led the way to the pub, followed by two people who live here. Turns out I know the most efficient routes between work venues and pubs, even in a town that I've never been to before.
  • Closing all outstanding Java driver pull requests, except for the one we want to merge but needs to be updated. This is a massive win for us, now we can actually stay on top of them instead of wondering which are valid and which ones we're actively ignoring. I hope the CTO isn't peeved I closed one of his from two years ago.
  • I got my highest scoring day on StackOverflow yesterday, receiving a "whopping" 67 points in one day. Be nice, I'm quite new to SO - despite being on there for over two years I'm really only just starting to feel comfortable there. One day I might actually ask a question.

In all seriousness though, I learnt a LOT this week. I've been with 10gen for about 9 months now, so although I feel like I should be a fully fledged member of the team there's still a lot I don't know about. In particular, as I hadn't used MongoDB before working here, and as I'm head-down on delivering the new Java driver (more to come on that later, I promise), I don't see a lot of how people actually use the database.

I've been lucky because this wasn't a heavy week for customer support, so I've been available to pick up "free" support - basically take a look at questions people are asking on StackOverflow and the MongoDB Google Groups and see if there's anything I can answer. Obviously I focussed on the Java side as this is the area I'm most comfortable (and there are only a few of us to answer those questions, and plenty of others to pick up more general questions).

So here are my Lessons Learnt:

Customers want to be heard

Responsiveness is almost more important to (paying) customers than detailed answers. They want to know that you've seen their problem, and you're on it. So sometimes it's best to answer a problem with a question or questions, asking for clarification on their situation and explaining any assumptions you have. It turns out that writing that long and detailed explanation of the steps they need to take isn't really necessary when you've figured out what they're really trying to do and response with "this is going to require production downtime". Suddenly it's not as urgent for them to fix this right now.

The Java Ecosystem is alive and well. In fact, it's a monster...

There really are a remarkable number of libraries/third party apps that people are using on top of our basic Java driver. This week, I've been trouble-shooting people using Morphia, Spring Data, Jongo, Grails GORM, as well as a lot of people who are using the driver directly. I've learnt a lot about installing and using all these things, as I've had to do that to reproduce people's issues and suggest solutions1. I've learnt that some of those things make life quite a lot easier, especially for the happy path of Java developers who simply want to save Java pojos into the DB and query for them afterwards.

I've also learnt that querying is quite inconsistent across all the libraries, and I'd say the main problem that users have is turning an understandable query from the shell into something that the library they're using understands.

Also, Dates get people every time, particularly in Java.

Where is the problem?

Related to the previous point, when a query returns nothing it's difficult to work out: if you're using the library incorrectly; if the Java driver doesn't support various options; or if the database isn't doing what you expect it to. More often than not the problem is not understanding how to use the tools (and the onus is on us, the library developers, to make it as easy and unsurprising as possible for developers), but sometimes it's a bug. Tracking down the root of the issue is important, because if it's a bug we should log it in the correct place, and if it's working as designed it suggests a lack of documentation or possibly a design flaw.

Having people to help you is dead important

I could have done this from home, from the London office, or even from the beach if I'd wanted to. However, I opted to come to our Dublin office where we have our EMEA support, because I knew that alone I'd try and dodge the work. Not because I don't want to do it, but because I don't know our processes, I don't know if we have a knowledge base I can use, I don't know if my answers are correct, and so on and so on. When you're uncertain, sometimes the easiest option is to run away. But when you're embedded in the team that does this every day, you can ask the stupid questions and get help rather than sit and feel stupid.

It's also nice to be part of a daily standup so you can hear what other people are up to, and it puts a (good) subtle pressure on you to do something so you have something to report.

What I like about support at 10gen

I've done support before. In fact, during my last year at LMAX I worked out I spent the same amount of time on the production support team as I did working on a team delivering new features. But since I've never worked for a product firm before, I haven't done this sort of support. 10gen makes its money by selling support contracts, so not only is it important to keep the SLAs with the paying customers, but it's also important to provide excellent quality support for them - with any luck they'll keep paying. It's also important for us to support those who don't pay - it's kinda like a teaser of the great quality they'd get if they paid us.

So the support organisation here is absolutely key to our bottom line.

The driver developers (of which I am one) are "strongly encouraged" to do a week of support every three months. We used to do days here and there, but blocking out a whole week to be part of the team, to be excused from your day job, and to leave your e-mail (and sometimes meetings) alone because you're busy doing support, works really well. I've felt very focussed on the support role during this week, and I've been motivated to do a good job. If I had been seconded to the team for a period of weeks, I would have dreaded the whole thing and have plodded along doing my time until my escape. Alternatively, doing it for a day at a time the support issues leak into the day job and the day job is hard to put down during your support hours.

I've learnt a lot this week. I have been lucky, I've had fairly straightforward issues to address and it hasn't been a busy week. But next time I see the support week looming in my calendar, I won't fear it as much. I'll probably do the next one from home, but my week here in Dublin has prepared me for what's in store. Most importantly, I've got to know the people who are part of my team here, so I'll be more comfortable asking the stupid questions.

In summary

  • Doing support is so important for developers. Getting an understanding of what your users are doing and what their pain points are can really help drive your design and your architecture, and can really motivate you to fix that stupid bug or write that overdue tutorial.
  • Developers and support techies can learn off each other - I've learnt a LOT off the guys here, but I've also been able to answer a few questions about Java in general and the driver in particular.
  • Scheduling time in support for developers is a very tricky balance, and probably needs to be experimented with a bit before a company finds something that works for them.

Although I'm never really going to love being on support, I still like being encouraged to work on support regularly - it's been so important for my understanding of our product and of our users.

1 I found Grails BY FAR the most difficult to get started with - all I wanted was to write a unit test to prove the issue, and I had to not only create a whole application using the grails command line, but I had to install a whole host of plugins and uninstall all the stuff for hibernate that gets put in there magically. I never did find the solution to the Grails problem I was looking at.