Tuesday, April 16, 2013

Attracting women to developer events

GirlDevelopIt SF is now 1,500 members strong, and all but a handful of them are women interested in learning to program, make websites, and generally become more technically literate. Because of my involvement in GDI and likely also because I'm a fairly visible "woman in tech", I often get approached with my thoughts on how other events can attract more women. As a general rule, I prefer to avoid talking about the women-in-tech-thing and instead spend my time doing stuff about it, but well, every once in a while, I decide to share some thoughts. Please note that these are only my thoughts, and do not necessarily reflect those of every woman everywhere.

Given that, here are some ideas on how you can lower the barrier for women to come to your developer events:


Offer a low cost option

There are numerous reasons why you might consider lowering the financial barrier for women attendees:

  • Women don't traditionally earn as much as men. Studies show that women in the same roles as men often don't earn as much, for a myriad of reasons.
  • Many women are up-and-coming developers, so they're not earning the developer big bucks yet. There is not a high percentage of women in computer science degrees at college, but lately, at least around these parts, there's a bit of an everyone-learn-to-code revolution and women are looking around and deciding that maybe that is what they want to pursue. This is probably my distorted opinion from running GirlDevelopIt, but basically, the majority of women developers I know are in the learning stages or the junior engineer stage, so I typically don't recommend expensive conferences to them.
  • Women may not feel as comfortable at the conference as the men, so they have less financial incentive to attend. We pay money for things that we think we will get a high value out of, and no pain. When I think about paying for a conference, I think about about the content but also about the atmosphere. Am I up for doing the whole only-woman-there thing? Do I feel like hanging out with a bunch of beer-drinking dudes? Sometimes I am, but sometimes I'm not, and especially if the conference costs money. Like everyone, I hate spending money on something that wasn't as good of an experience as I'd hope. I hate wasting time, too, but somehow that doesn't feel as bad. (And if I went to a conference for free and didn't like it, I could just leave, which I admittedly have done.)

How do you actually lower the financial barrier? There are a few ways:

  • Offer a scholarship that women can apply for. You can offer this out of your own event funds or partner with someone to be their official sponsor. Put together an application form that finds out what their need is like and how interested they truly are in the event. Organize a breakfast or lunch for scholarship recipients, so that they feel an obligation to show up and get an excuse to meet other people (meeting people at events is hard, especially if you're not a chronic-event-attender).
  • Offer free or discounted tickets for women groups to give out. You can find local groups like WomenWhoCode or GDI, contact their organizers, explain sincerely why you think the conference would be of interest (don't send a damn form letter) and offer them discounted tickets.
  • Make your event free for everyone. This is an option, but it will effectively lower the barrier for *all attendees*, so if you do this, you need to go through effort to target women specifically, way more than men. Google recently put on DevFestW, and they did outreach through all of the local women groups and got up to 60% RSVPs of their cap before they advertised it to the general public. If they'd advertised it to the general public at first, it would have likely filled out with mostly men, just for statistical reasons.

Increase the value proposition

I have an anecdote-based theory that to some attendees, a conference is attractive merely because it is an excuse to drink and socialize with like minded folks. Well, I personally don't get attracted to conferences for that, because I don't always like drinking (especially with strangers who I have yet to develop trust in), and because I don't always know that I'll find like minded folks there. When I go to a conference, it's because I'm excited about what I will learn at the conference, what speakers I will get to meet (like the authors of tools I'm using), and hey, if it offers kayaking on the side like JSConf is this year, I'll get excited about that too.

Given that the value proposition of a conference may matter more to women (or atleast me), here is what I suggest:

  • Publish everything you know about the speakers and topics covered as soon as possible. Some conferences are well known enough that they attract attendees on their name alone, but that means that you are only attracting the attendees that already know the conference and have confidence in its value to them. If you want to attract women, most of them will be new attendees (given the low % of women attendees currently), and they may want more information than the brand.
  • If you do not have all the information published when ticket sales start, save some tickets. I often wait until I see a conference agenda and find out who else is going before I decide to attend it, but for more popular conferences, that sometimes means the conference is sold out by the time the value proposition is clear. If you are starting ticket sales before the full value is clear, then you might consider saving tickets that you can announce at later times, or offer through other channels.
  • Encourage previous attendees to recommend it to their (women) friends. Just like we trust restaurant recommendations from our friends more than other sources, I'm more likely to think that a conference will be beneficial if a friend tells me so.

Lower the intimidation factor

A conference can be a scary place. Hundreds of strangers milling around, an expectation of networking, content that might go too far over your head. For a woman, it can be even scarier because we stand out (so we do not have the option to blend in), and because we may suffer from imposter syndrome.

Here are a few ideas on improving that:

  • Clearly message the intended level of the conference, or make it beginner friendly. This reduces the fear of mismatched content level. For much more detailed thoughts on making an event newbie friendly, see this blog post.
  • Organize groups of women attendees. New things are less scary when we have a support crew, and that's something that you could encourage to make your event less scary. You could reach out to women groups and encourage them to make a Meetup out of it (and maybe they'd meet up for breakfast at the conference), or you could offer discounted rates to 2+ women attending together. You could also incorporate social networking into your ticketing process to see if that makes it easier for attendees to find other potential attendees.

Wrapping up

To summarize all of the above, I'd say: It's harder for women to know which events they will gain the most pleasure/experience the least pain, and they will tend to attend those with the clearest value proposition, lowest cost/commitment, and lowest intimidation factor.

Once again, I want to reiterate: these suggestions are based on my experiences, and do not necessarily reflect the views of other women. I know that some of my suggestions are along the lines of Affirmative Action, and there is much debate along those lines. I do not want to inspire heated debate, I just want to put my food for thought out there, and hopefully it can be helpful to some of you. I'd love to hear in the comments what has worked or not worked for your own events. Thanks!

Saturday, April 13, 2013

Making newbie-friendly developer events

GirlDevelopIt is all about welcoming and teaching newbies. Most of our students are completely new to web development, and they come to us because we try our best to provide a newbie-welcoming environment and get them over that newbie hump. Some of our students stop at the intros, others of them continue on to turn into 24/7 developers.

Since we have a membership of 1,500 women that are atleast marginally interested in development, we often get approached by other event organizers that want to get more women at their events, and are hoping we can give them advice and advertise their event to our members.

My first response to them is always: "Is it newbie friendly?"

You see, most events are not newbie friendly, or at least not marketed that way. Many of them are actually the exact opposite. For example, you might see a hackathon that says "Are you a coding ninja? Compete to see who can hack the most in a weekend" I'm sorry, but you're not going to get newbies foaming at the mouth to come to that event. Nobody wants to attend an event where they don't feel wanted.

So, here's the first question you should ask yourself: "Do you want to be newbie friendly?"
Maybe you only want to attract experienced developers. If that's the crowd you're going for, then that's totally fine, just be aware that you've made that decision.

If you actually want to attract more beginner level developer, though, you will have to do a bit more work to do it well. Here's what I'd recommend:

  • Provide beginner level content at your event. Either it should all be beginner level, or there should be continuous parallel tracks for the different levels. If only one small part of your event is at a beginner level but the rest isn't, then you will likely not get many beginners, or you'll get beginners that feel overwhelmed most of the time.
  • If your event itself doesn't have a beginner track, then offer events in the weeks leading up that will cover the prerequisite knowledge. For example, when I put on a 3-day Google APIs hackathon in college, I realized that my computer science classmates were effectively newbies in web development, and we organized a 2-week series of workshops before the hackathon to get them up to speed. For another example, when we wanted to get a lot of GDI members at the Everyone Hacks event but we realized that many of them were new to hackathons, Adria Richards gave a great workshop on "How to Rock your First Hackathon" to answer their doubts and build up their confidence.
  • Make it very clear in your marketing material what the prerequisites are, and be as specific as possible. Even when we list prerequisites for our GDI workshops, we get questions from students who still aren't sure if it's at their level. Beginner students are inherently not experts, so it won't be as obvious to them as it is to you what their level is and whether it's appropriate.
  • If your event targets multiple levels of expertise, make that clear, and maybe give attendees the option to specify their level. For example, if you're listing ticket types for a hackathon and one of them is "Super Hacker", then you should also have a ticket type for "First time Hacker" (like in this sign up). You might say elsewhere that it's okay to be beginner level, but damn if I'm going to identify myself as a "Super Hacker". Beginners are easily intimidated. (Well, we all are, actually.)

Here are some ideas specifically about hackathons. I really think hackathons can be a fantastic experience, which is why I encourage our members to attend them, but I also think that they can be the most intimidating, since there are so many opportunities for beginners to feel bad for being a beginner.

  • Sign up people ahead of time to be designated coaches for newbie teams. In their pitches, the coaches can say "And I'm looking to mentor a team of beginners, so if that's you, join me!" Liz Howard did that at our Everyone Hacks event, and I think it relieved a lot of beginners who were worried about being a drain on an experienced team. When we had our pre-workshop on "How to Rock your first Hackathon", the question that we got over and over is "how we will find a team to join?", so its worth it to spend time figuring out how team formation will work at your hackathon. Consider the case of strangers, beginners, shy folks, etc, and find something that will work for all of them.
  • Sign up mentors to wander around and help anyone that looks lost. A team coach can't always do it all, and it can be exhausting to mentor 24/7. At Everyone Hacks, my team decided to use Ruby on Rails, which I'm not familiar with, but luckily a Rails expert floated around and helped our team get it all up and running.
  • Make the hackathon less about competition and more about collaboration. Maybe that means making prizes for best team spirit or best idea, and maybe that means massaging the messaging in the marketing. The best thing about a hackathon is the people that you meet, anyway, so it doesn't hurt to put more emphasis on that aspect.

I'm not professing to be the world's expert on this, of course. This is just what I've observed during my experiences in GirlDevelopIt and the many developer events I attend. So, what do you do in your events to make them newbie friendly?

Wednesday, April 10, 2013

Outputting iCal with PHP

I'm a big Google Calendar user. If I don't have it on my calendar, then it's probably *not* going to happen. If I'm trying to schedule something into my week, then I'm always consulting my calendar to see how it fits in with everything else, or if its making my week too busy. And, hey, I'm pretty sure I'm not the only GCal addict out there. (Oh, and before GCal, I was totally a Yahoo! Calendar user. Retro!)

So, when I first joined Coursera, I brought with me a list of ways I wanted to improve the student experience, and one of those was "Create a Google calendar of deadlines."

I was hoping this would be an easy thing, something I'd do in my first month. Of course, I didn't realize then that our legacy codebase was a tangle of PHP, that it was split across 5 git repositories, and that it was largely untested. So I repressed my dreams and worked on improving our architecture so that features like that *would* be an easy thing.

Well, as I just announced on the Coursera blog, I finally got to a place where I could write and test the feature, and we've started surfacing it on our classes.

I still had to write it in our legacy PHP codebase, but I don't actually mind PHP when it's written relatively cleanly and testable. I found the hardest part was figuring out exactly how to format my ICS files, and I spent a while going back and forth between this handy iCal Validator and the rather boring iCalendar specification.

I started by writing 2 general classes - CalendarEvent for generating VEVENTs, and Calendar for generating VCALs. Here's the most important function of the CalendarEvent class, the one that generates the string based on the event data:

public function generateString() {
  $created = new DateTime();
  $content = '';

  $content = "BEGIN:VEVENT\r\n"
           . "UID:{$this->uid}\r\n"
           . "DTSTART:{$this->formatDate($this->start)}\r\n"
           . "DTEND:{$this->formatDate($this->end)}\r\n"
           . "DTSTAMP:{$this->formatDate($this->start)}\r\n"
           . "CREATED:{$this->formatDate($created)}\r\n"
           . "DESCRIPTION:{$this->formatValue($this->description)}\r\n"
           . "LAST-MODIFIED:{$this->formatDate($this->start)}\r\n"
           . "LOCATION:{$this->location}\r\n"
           . "SUMMARY:{$this->formatValue($this->summary)}\r\n"
           . "SEQUENCE:0\r\n"
           . "STATUS:CONFIRMED\r\n"
           . "TRANSP:OPAQUE\r\n"
           . "END:VEVENT\r\n";
  return $content;
}
And the function for the Calendar Class that generates the string of events:
public function generateString() {
  $content = "BEGIN:VCALENDAR\r\n"
             . "VERSION:2.0\r\n"
             . "PRODID:-//" . $this->author . "//NONSGML//EN\r\n"
             . "X-WR-CALNAME:" . $this->title . "\r\n"
             . "CALSCALE:GREGORIAN\r\n";

  foreach($this->events as $event) {
    $content .= $event->generateString();
  }
  $content .= "END:VCALENDAR";
  return $content;
}

Here's an example of using those classes to create a calendar with one event:

$event_parameters = array(
            'uid' =>  '123',
            'summary' => 'Introduction Quiz Deadline',
            'description' => 'Make sure you check the website for the latest information',
            'start' => new DateTime('@'.($time - (60*60))),
            'end' => new DateTime('@'.$time),
            'location' => 'http://class.coursera.org/ml/quiz/index?id=2'
        );
$event = new CalendarEvent($event_parameters);

$calendar = new Calendar();
$calendar->events = array($event);
$calendar->title  = 'Machine Learning Deadlines';
$calendar->author = 'Coursera Calendars';
$calendar->generateDownload();

In our own code, I wrote two more classes to help with generating those events for our own data, CourseItem and CourseCalendar (a subclass of Calendar).

You can check out the Calendar classes in this gist. If you've worked with iCalendar files in the past and know anything that we should be tweaking about what we're outputting, let me know more in the comments.