Wednesday, March 25, 2015

GHC proposals: Rejection likely

The Call for Participation for Grace Hopper Celebration just closed last week, and I saw a flurry of proposal submissions on Twitter. I am very excited to see so many people stepping up to speak, but I have some bad news:

Your proposal will probably be rejected
Your proposal will probably be rejected

GHC attracts a lot of proposals. A lot. Women from all walks of computing submit their talk ideas. In the past years I have heard a lot of excellent proposals being rejected. Bottom line, it is a very competitive process.

Don't waste your proposal

Now that you have written your proposal, you should submit it to other conferences. There are always conferences looking for speakers. Some resources:

Still not sure? Tweet me and I will recommend conferences to you.

Monday, March 23, 2015

Sketchnoting: An Engineer's Approach

Write/Speak/Code is the first conference I tried sketchnoting, and people loved it. I was really surprised because I still consider myself someone who cannot draw, but somehow I am good at sketchnoting. How come?

Constraint satisfaction problem

Naturally, I will explain my approach with a sketchnote:

When I took Alexis' sketchnotes class three years ago, I was really hung up on the idea that I needed to draw. The repertoire of shapes and objects that I can draw is really small, so I never actually tried sketchnoting after the class.

What changed? I flipped the problem around. I phrased it as a constraint satisfaction problem. I am using a small toolbox to express ideas I heard. And as an engineer, I am extremely good at that.

In the sketchnote above, I wanted to convey the idea that illustrations do not need to be realistic. At first I wanted to draw two trees, one realistic, one not. But alas, I cannot draw a realistic tree. Instead of giving up, I worked around by drawing a box with a dotted line to represent the realistic tree that I am unable to draw. Problem solved.

I am not kidding when I say my toolbox is small. You can see it in the sketchnote. The plain old notes vs sketchnotes part. That is literally my toolbox.

Use a pen

The other breakthrough came when I saw The Sketchnote Handbook by Mike Rohde in my local library:

The most important thing I picked up from the book is to use pen instead of pencil. This forces me to always make progress instead of erasing and re-drawing and second-guessing myself. It also makes me more forgiving of my mistakes, and come up with creative ways to fix them.

In the toolbox about bullet lists, I made two bullets with stars, because a single bullet doesn't make a list. And then I realized that I have nothing to more to say. What to do? The second star was already drawn. With ink.

I ended up writing "There is no second point" next to the second star. And you know what? It now emphasizes the fact that it doesn't take much to make sketchnotes.

A lot of serendipity came from using a pen and being forced to make things work.

Find your style

I really enjoyed the The Sketchnote Handbook because it includes examples from many sketchnoters. I pick and choose techniques that works for me:

  • Some sketchnotes are very free form, popping images left and right seemingly randomly. That terrifies me. But many examples use a grid style. I came up with my own layout algorithm: top to bottom, and if an item took too little horizontal space, put something next to it. This is very similar to traditional note taking, just using a bit more horizontal space. I can do that.
  • Some sketchnotes fill the whole page, and the pressure to do so paralyzes me. But many examples have whitespace between the items, and that is totally okay.
  • The book recommended using a vertical layout for panels, drawing the face of one panelist on each column. There is no way I can draw portraits. So I skipped that part. But it also showed a few simple ways to draw people. Now Starfish Man is a regular cast member in my sketchnotes.


This is the most potent motivator: Twitter. You know how some people take a screenshot of a block of text to get around the 140 character limit? That looks stupid. But I can totally post a sketchnote to stuff more content into a tweet. And it looks awesome. So awesome that I get lots and lots of retweets, which gave me the confidence to do more sketchnotes, which gets more retweets.

Gotta love that positive feedback loop!

Sunday, March 22, 2015

Write/Speak/Code: Code

The third day of Write/Speak/Code is dedicated to contributing to open source.

Speaker buddies offsite

I have known my fellow writing panelist Corey Latislaw for a while, and we have always been speaking buddies, pushing and supporting each other. Rather than attending code day, we decided to have an offsite to catch up.

Yes, we played hooky for a leisurely brunch at Feast and a lovely walk on High Line. And we talked about our next steps as public speakers, brainstormed talk ideas, and plotted the steps to make it happen. This is the hallway track taken to the next level :)

The art of being awesome

We headed back to the conference just in time for Jen Myers's talk.

The awesome machine

Write/Speak/Code is a great combination of practical advice and dedicated time to write, to speak, and to contribute to open source. It is also a congregation of amazingly awesome women, pushing and supporting each other. Everybody is super charged with energy, ready to take their endeavors to the next level. Or as Buzz Lightyear puts it, to infinity and beyond!

This is a part of the Write/Speak/Code series. Read more: Intro, Write, Speak.

Write/Speak/Code: Speak

The second day of Write/Speak/Code is dedicated to speaking: writing a talk proposal, and giving a lightning talk.

Work in pairs

We started the day with a few exercise to brainstorm talk ideas and find a partner with similar interests. Each pair worked together throughout the day to write the talk proposal and prepare the lightning talk. Thisbuddy system is a brilliant idea, not only to bound off ideas during the day but also to hold each other accountable after the conference ended. I hope everyone will keep in touch with her partner and push each other to propose to conferences, help each other refine the talks, and cheer for each other as we all step on the stage!

Conference Organizer Panel

To help us write better proposals, Write/Speak/Code put together a panel of conference organizers, sharing their experience on the other side of the table.

After the panel, we split into small groups, and speaker mentors gave feedback to the talk proposals written earlier.

Speaking Effectively About Your Work

Next lecture is from Melissa Collom on how to create engaging presentations.

Lightning talks

Just like Write day ended with writing, Speak day ended speaking: give a lightning talk! Each talk was recorded, so everyone received feedback on the spot and can also go back to watch and review their talk.

This is a part of the Write/Speak/Code series. Read more: Intro, Write, Code.

Write/Speak/Code: Write

The first day of Write/Speak/Code is dedicated to establishing credibility, then sharing expertise through writing.

Impostor Syndrome

After the introduction from Write/Speak/Code founder Rebecca Miller-Webster, the first order of business was to address the impostor syndrome. Neha Batra gave us a 6-step formula to fight it:

Own your expertise

Next we went through a bunch of exercises to come up with our expertise based on our knowledge and experience.

With that, we crafted a bio and brainstormed ideas to write or speak about.

Writing panel

I really like how Write/Speak/Code alternates between hands-on activities and lectures/panel. Next up is the writing panel, and I got to share my experience alongside Pam Selle, Debra Williams-Cauley, Julie Steele, and Corey Latislaw.

Writing sprint

We concluded Write day by writing a blog post. I just stepped off the writing panel, and realized that I forget to share my blogging formulas, so I ended up writing a blog post on how I write conference reports. Oh so very meta!

This is a part of the Write/Speak/Code series. Read more: Intro, Speak, Code.

Write/Speak/Code: Intro

When I heard about Write/Speak/Code, I know I want to be a part of it. My career has benefited tremendously from writing blog posts, speaking at conferences and sharing my code as open source, and I want to empower other women developers to do the same.

Make it happen

Once I decided that I want to help out at Write/Speak/Code, I need to figure out how to make it happen. I met Vanessa Hurst while we were both speaking at OSCON 2013, and she co-founded Write/Speak/Code, so I reached out to her. She put me in touch with the organizing committee, and while I was waiting for results from mentor nomination and selection, I decided to write a blog post in the spirit Write/Speak/Code and send that to the organizing committee. A few weeks later, they invited me to be on the writing panel and also be a speaker mentor. Yay!

I normally don't share stories like this, but I feel this is appropriate for Write/Speak/Code. If you want to speak at a conference, there are many ways to get in the door. Answering to an open CFP (Call For Proposals) is one way, but you can also reach out to the organizers directly. If you don't know them, get an introduction. Make it happen.


Write/Speak/Code is a 3-day conference, each day dedicated to Write, Speak and Code:

  1. Write
  2. Speak
  3. Code

Yup, the conference is so jam-packed with action that I need to write a separate blog post for each day! Click on each link above to read more.

Thursday, March 19, 2015

Blogging formula: Conference reports

I wrote about my formula for writing technical articles. I also have one for trip reports, to talk about conferences I attended. Having a fixed structure means I can plug in the content from the conference and publish the blog post a day or two after the conferences ended, while it is still fresh on people's minds.

Here is my formula, using Øredev as an example.

1. Introduction

I introduce the event many different ways:

  • Explain why I was there.
  • If I was speaking, talk a bit about the CFP process.
  • Pull out one interesting thing from the conference.

Here is what I said about Øredev:

When Cate and I was touring Copenhagen, we talked about how we got into public speaking. One thing led to another, and we decided to publish a newsletter together. We had a little bit of time on Monday before Øredev, so we put together our first issue in the hotel lobby!

2. Highlights

I point out things that I enjoyed. This is pretty easy because I tweet during the conference, so I just embed the tweets in my blog. I also search for the conference hashtag and include other people's tweets.

I also include photos from the events. Photos are great because they take so much space that you post looks rich even if you did not write many words. Same goes for embedded tweets.

Selected tweets from Øredev:

3. My talks

If I was speaking, I mention my talks, embedding or linking to slides and videos if available. Usually I keep this pretty short, assuming people can check out the slides or videos if they are interested.

My talks at Øredev:

4. Conclusion

Quick summary of my general impression, usually just a sentence or two. This is what I said about Øredev:

Tack så mycket, Øredev!

Exercise for the reader to figure out what it means :)