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

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.

Moar technical articles!

You need to write more technical articles.

Yes, you.

I could guilt you into doing it. I could tell you that you have benefited from other people's sharing so much that it is time for you to give back.

But instead I will tell you what is in it for you: Job security.

Your real résumé

The classic first step to get a job is to prepare a résumé. It could lead you to an interview if you keyword-stuff it the right way. But nowadays employers are turning to the internet to cross check if you are who you claim. A repertoire of technical articles is a solid way to show that you know your stuff, and more importantly, you can communicate.

But what do I write?

I knew you would say that. While I have no guaranteed formula that works for everyone, I can share how I make writing technical articles a part of my normal workflow.

1. Experiment on a clean slate
   Whenever I need to incorporate an unfamiliar technology into my work, I do not do it directly in my main project. Instead, I create a brand new project and implement the minimal setup to understand how it works.

2. Build it up step by step
   Once I get the minimal setup working, I add extra logic to get to what I need. But instead of overwriting the minimal setup, I make a copy so that I can explain the steps later. For example in Android apps I make my MainActivity a list of activities, each corresponding to a step.
3. Integrate into the main project
   When the sample project has all the functionalities I need, I put it into my main project. It may interact with my existing code in unexpected ways, so I tweak until it works.
4. Write the article
   After the coding is done I write the article. This is the structure I use:
   1. A back story of what I was trying to do
   2. Outline the steps I took with code snippets and screenshots
   3. Explain the problems I encountered along the way, and how I solved them
   4. Link to source code on github
5. Push the sample project to github
   I don't publish my source code until the article is written because sometimes I thought of a better way of doing things while explaining my method in writing. Once I am happy with the article, I push my repository to github, publish the article, then add a link from the README of the github repository back to the article.
6. Share on social network
   After everything is published, I post a link to Twitter and Google+ with a screenshot as the teaser.

End result

Here is a sample article: Partial SlidingPaneLayout

And how I shared it:

Good for you, good for others

I stumbled upon this workflow by accident. I used to stick the new technology straight into my main project, failed to make it work, and unable to pinpoint why. With a brand new project I can focus on the new stuff, work out all the kinks before I introduce the extra complexity of my main project.

Once I figured out how it works, I could have just thrown away the sample project. But what a waste! Instead I push it to github, and suddenly I am an open source contributor. Sweet!

Writing the article is a bit of extra work, but so very worth it. It gives me credibility. It lets people know that I know my tech, and I know how to explain it. Icing on the cake? It helps other people too!