Wednesday, December 30, 2015

Taking stock of 2015

I was inspired by this post by femgineer to write my own post about acknowledging my accomplishments of the past year.

One of my 2015 resolutions was a continuation of the previous years' - Be more active in the tech community. This goal was big enough to try out different things so I pretty much said YES to any opportunity that came along.

2015 was my year of firsts. Here's my list of tech accomplishments in chronological order:
  1. First-time team lead at work
  2. Submitted my first abstract to a conference (and many more after that!)
  3. Wrote my first blog post
  4. Gave my first technical talk at the Android Alliance meetup
  5. Gave my first technical conference talk at AnDevCon Boston (and DroidCon NYC after that!)
  6. Hosted my first luncheon at AnDevCon Boston
  7. Was a first time panelist on Girl Develop It's A Day in the life of a Developer series
  8. Was interviewed for the first time on Youtube for Android Dialogs
  9. Gave my first non-technical conference talk at ElaConf
Writing this down inspires me to continue doing a lot more in 2016!

Image Credit

Sunday, November 29, 2015

My first non-tech talk at ElaConf

I gave my first non-tech talk at ElaConf Nov 2015 last weekend. ElaConf is a conference that empowers women in tech and its proceeds all go to Girl Develop It. Learn more about it at Why do I call my talk non-tech? Because the talk does not feature any code and it does not feature any technical problem that I solved.

My talk was titled "Preparing for your first talk" but it's applicable to anyone who is preparing for any kind of talk - technical or otherwise. I was inspired to give this talk after writing this detailed blog post on how I prepared for my first big conference.

Some of my tips and tricks were very well captured by the wonderful artist who was sketch-noting at the conference as well as one of the attendees.

One of my suggestions was to wear a blazer to cover food spills. (True story: This happened to me at AnDevCon moments before I went on. My blazer saved the day!) A lot of attendees loved this and tweeted it out!

I wouldn't have been able to give this talk without the wisdom of the people who have done this before me so I'm listing all of the resources I have used over the past year:

Technically Speaking
Technically Speaking is a newsletter with information on call for proposals and public speaking, with a focus on technical topics by @chiuki and @catehstn.

Write/Speak/Code empowers women software developers to become thought leaders, conference speakers, and open source contributors.

Blog: Femgineer
Book: Present Book: A Techie's Guide to Public Speaking

Garr Reynolds' Prezentation Zen
Presentation Zen: Simple Ideas on Presentation Design and Delivery
The Naked Presenter: Delivering Powerful Presentations With or Without Slides (Voices That Matter)

Scott Berkun
Book: Confessions of a Public Speaker

TED Talks

Monday, August 3, 2015

How I prepared for my first big conference talk

Last Friday, I gave a talk at AnDevCon Boston. I had about 4 months to prepare since the conference's Call for Proposal(CFP) deadline was in March and the conference was in July.

I have broken down my entire process of giving a presentation - from writing an abstract to giving the final talk into the following steps:
  • Choosing a conference and submitting a proposal
  • Breaking down the topic into smaller components
  • Giving my talk at a local meetup
  • Prepping for the conference
  • Prepping hours before the talk

Choosing a conference and submitting a proposal

The whole process of giving a talk started at the Write/Speak/Code conference which happened earlier this year in March. On Day 1 of the conference, I wrote down several topics that I have expertise in. I settled down on one topic which I knew would benefit several Android developers: Monetization. I wrote a quick abstract which was reviewed by attendees and mentors at the same conference. I was paired with a mentor and we quickly put together some slides and gave a 5 minute lightning talk on Day 2. I looked up upcoming Android conferences and AnDevCon Boston's deadline was a few days away so I went ahead and submitted the abstract I had written.

Now, not everyone has access to mentors or peer review when writing an abstract for a conference. So for those who are starting out, an abstract is generally about 400 words long that describes what you are going to talk about in your tech talk. Here's my abstract from AnDevCon Boston.

Time spent to write abstract and get it reviewed: 2 hours
 spent to prepare for a lightning talk: 2 hours
Time spent to give the ligthing talk: 5-10 minutes
Time spent to submit a proposal to a conference: 15 minutes 

Breaking the topic down into smaller components

When I first started out writing down my main talking points, I wanted to cover a lot of things. I jotted down all my thoughts on paper and on a giant google doc. I went through the documentation, code and Google I/O videos, discovered things I hadn't known before, and recalled a lot of the challenges and solutions on the topic. I gathered all of these notes into 7 smaller components.

Time spent to prepare: 8 hours

Giving my talk at a local tech meetup

I got in touch with the organizers of Android Alliance Philly where my talk was most relevant (since it is about monetization on Android) and told them that my proposal had been accepted. I was given a time slot of 45 minutes. Once I had the deadline and time limit, I refined my lightning talk slides, added new diagrams using and practiced my talk. I audio recorded myself and made sure to continue even when I made grammatical mistakes or struggled with segues into the next slides and sections. I listened to my recordings a few times to improve myself. The third time around, I was confident enough to give the talk without looking at my notes and without stopping.
I gave my talk at the Android meetup as mentioned in one of my older blog posts. The audience asked a lot of relevant questions which I noted down so I could cover them in my AnDevCon talk.

I also asked the attendees to fill up a feedback form with these questions and some of them actually did!
  • How did the speaker do?
  • How was the pace of the talk?
  • Did you get a better understanding of monetization on Google Play?
  • Would you recommend this talk to someone?
  • Was this talk useful to you? Why or why not?
  • Do you have any other comments?
Some of the feedback was that the code was too hard to read from the back, the diagrams weren't clear enough and that I needed to spend some time talking about the big picture before diving into the details.

Time to prepare slides: 4 hours
Time to practice talk: 3 hours

Prepping for the conference

AnDevCon Boston had a deadline for slide submission two weeks before the conference. A few days before the deadline, I refined my slides from the local talk and used Google Draw to draw new diagrams. I googled around to figure out the minimum sizes for font and lines on slides and went with 24 point for fonts  and 4 px for lines in diagrams. I tried to transition to Keynote but settled on Google Slides since I was already familiar with it. I practiced my talk before submitting slides to make sure the transitions between slides were smooth. 

Once the slides were submitted, I had two weeks to practice my slides. Since the time slot was for 75 minutes, I could only practice once every few days. I audio and video recorded myself every time so I could keep track of the time, my nervous ticks and my filler words (umm, uhh).

I also emailed the conference organizers to ask them logistical questions such as microphone availability, audience demographics, wi-fi access, number of projector screens and so on. A complete list is available at Questions to ask Conference Organizers

Time to prepare final slides: 4 hours
Time to practice talk: 3 hours

Prepping hours before the talk
I had the last time slot on Day 3 of the conference for my talk. I practiced once every night after Day 1 and Day 2 of the conference without my notes. I audio and video recorded myself to make sure I was within the time limit and had about 10 to 15 minutes to spare for answering questions. 

I also incorporated some of the tactics used by other speakers to engage the audience like asking them a few questions so that they could answer with a show of hands, asking them their names when they asked a question and repeating audience questions. (I vaguely remember doing some of these once I was at the lectern talking.) On the morning of the conference, I got up early to practice one last time. 

Time to practice talk: 3 hours

Over the months leading up to the conference, I read several blogs and email newsletters about public speaking and this amazing book - Confessions of a Public Speaker by Scott Berkun twice! I have listed some helpful links below:

My motivation for preparing so much was because I wanted to make sure I gave a good talk that would show that I had done my research and was worth everyone's time. 

I hope it was great so I'm invited to speak again. It was a fun and harrowing experience but I would do it all over again!

Thursday, May 7, 2015

At GDI Philly's Day in the Life of a Developer Panel

My local GirlDevelopIt chapter @gdiphilly is running a 5-event career speaker series titled "A Day in the Life". I recently had the opportunity to be on "A Day in the Life of a Developer" panel which was aimed at women transitioning into tech and curious to know what a developer does every day. The panel was very diverse with three women from a Humanities background and two from a Computer Science background.

We started off with each panelist's perspectives on the following questions. Some panelist answers are mentioned below:

How did we get into this field?  
Early interest in math and science, Went to Engineering school, Transitioned from a tech support role, Took some Computer science intro classes.

What is our educational background? 
Engineering, Photography, Humanities, Art History

What are our daily responsibilities? 
Coding, Building new features and maintaining existing ones, Managing developers, Troubleshooting, Debugging

What does our typical day look like? 
Writing code, Reviewing code, Attending Meetings, Discussing on Github/Slack

What are the good parts of being a software developer? 
Learning new things everyday, Coaching people, Being an expert resource in the field

What are the bad parts of being a software developer? 
Meetings, Sitting for a long time, Talking tech to non-tech people, Internet Explorer!

What career advice do we have to offer?
Take GDI and online classes, learn Git/Github, volunteer at local tech meetups, attend hackathons, take part in open source programs, build a community that supports you, break down problems into smaller ones, don't compare yourself, make mistakes and learn from them, blog/speak about your learning experience and do what's best for you.

The floor was then open to Q&A. Some questions asked by the audience were:

Is it worth getting a Computer Science degree? 
It depends on what you want. Getting into tech does not necessarily require a Computer Science degree but having one helps get your foot in the door. You can also get degrees online through MOOCs and take local classes to figure out where your interests lie.

Is there sexism in tech?
Occasionally but you should call people out when they do it since they could be unintentionally sexist. Calling them out helps change their attitude.

What is the interview process like?
It varies. Small, medium and big companies do it differently. There could be white-boarding (writing code on a white board), phone screens, pair programming, and questions about data structures and algorithms.

Special shoutout to @suzienieman for moderating the panel and setting up the event! Overall, it was a wonderful experience and I loved being a part of it! 

Thursday, April 30, 2015

My first talk!

I gave my first talk at Android Alliance Philly yesterday on Monetizing Android apps with in-app billing on Google Play Store. The audience was wonderful, asked a lot of questions and gave me plenty of ideas on how to improve my talk and presentation.

Kudos to @corey_latislaw who live-tweeted and sketch-noted while I talked. What an amazing way to remember things!

I'm looking forward to giving this talk at AnDevCon Boston in July!

Link to my slides: Monetizing Android apps on Google Play Store

Saturday, March 28, 2015

Amazon Kindle Fire cheat sheet for Android developers

My company recently published our Android app on the Amazon app store for Kindle Fire tablets. While getting ready to publish the app on the store, I realized that the list of Kindle Fire specifications that Amazon has here is neither developer nor customer support friendly.

Kindle Fire devices show system version in this format: 7.5.1_user_5170020. 

This does not convey the Android OS version at first glance. So, if a user or a customer support representative says that your app is not working on a Kindle and they only give you the system version, you as a developer are not sure which version of Kindle it's failing on.

If you are also debugging via USB on a Kindle device, Android Studio only shows you the Build Model and not the OS version.

To solve these issues, I made the cheat sheet below to help Android developers quickly determine which Android OS version a Kindle is on. Hope this helps!

Note: This table is as of March 28 2015.

Build Model Name Screen Size Status Android OS Fire OS Device -> Latest System Version Screen density
KFSAWA or KFSAWI HDX 8.9" 4th gen 8.9 New 4.4.2 4 xhdpi
KFASWI HD 7" 4th gen 7 New 4.4.2 4 hdpi
KFARWI HD 6" 4th gen 6 New 4.4.2 4 hdpi
KFTHWI or KFTHWA HDX 7" 3rd gen 7 New 4.4.2 4 updated from 3 updated from
KFAPWA or KFAPWI HDX 8.9" 3rd gen 8.9 Legacy 4.2.2 4 updated from 3 updated from
KFSOWI HD 7" 3rd gen 7 Legacy 4.2.2 4 updated from 3 updated from
KFJWA or KFJWI HD 8.9" 2nd gen 8.9 Legacy 4.0.3 N/A 8.5.1_user_5156520 hdpi
KFTT HD 7" 2 gen 7 Legacy 4.0.3 N/A 7.5.1_user_5170020 hdpi
KFOT 7" 2nd gen 7 Legacy 4.0.3 N/A 10.5.1_user_5170120 mdpi
Kindle Fire 1st gen 7 Legacy 2.3.3 N/A 6.3.3_user_4112920 mdpi

Downloadable Kindle Fire System Updates
Kindle Fire Specifications