RailsConf 2015 recap

I had an AMAZING time at RailsConf this year! A couple weeks before the trip, a coworker asked me whether I was excited about it, and I said I hadn’t had time to feel excited because I was worrying over my talk so much (which was about 1-2 weeks behind in prep time than last year’s). But I got it all done in the end with just the one close-to-all-nighter and followed most of my own tips/lessons learned from past conferences.

Recommended talks (I may update this as more things come back to me):

• Women Who Code Soirée featuring a Chat with Sandi Metz: this was probably the absolute highlight of the trip for me! Notes from this forthcoming.
• Sandi Metz's talk "Nothing is Something", on the null object pattern: video (35:00), slides
• Sara Chipps' closing keynote on day 1 (dancing drone demo!)
• "How Does Bundler Work, Anyway?" by Andre
• Hsing-Hui's lightning talk on empathy & vaccinations analogy: video (4:45), slides
• Crowd-sourced favorite talks on Twitter

These were some of the key items for feeling good about my talk. I also had an excellent time slot again, the first one after lunch on the first day! So it's totally worth it to put in a polite request for that to the conference organizers.

Before the talk:

• I stayed at the speaker dinner the night before through dessert but then got myself back to my room by 10. And then I didn’t stay up too late after that just for practicing.
• I told my friend David to come sit in the front row at my talk so I’d have a friendly face there right there.
• I overpacked to have more choices, but I think I've settled on either a button-down shirt or dress for wearing while presenting instead of t-shirt + hoodie. I like that slight extra feeling of being more put together.
• I skipped the second morning session so that I had all of that plus lunch until my talk to stay calm and not talk to people. I had meant to do a couple last practices the morning of but found myself not really interested in doing so, so I let it go.
• I got to the room early to get everything hooked up and then didn’t want to go far, but also didn’t want to be around people before my time slot started…so I ended up just sitting on the floor behind the podium, hidden from sight. I wonder what the attendees thought when I sort of just popped up a couple minutes before I was supposed to start? Heh.

During the talk:

• I gave myself permission to just stay safely behind the podium. Some day I’ll practice getting out from behind the podium but for this talk, I was focused on having a clear delivery of my first talk with code in it.
• When I messed up in the bullet points I was looking over on a slide, I didn't let it derail or rattle me, I just noted it, fixed what I was saying, and then moved on.
• When people chuckled at something I’d said or one of the images on my slides, I paused to give the space needed for that before moving on, so I didn’t rush things along unnecessarily.
• I set up my slides so that while I did a lot of line-by-line builds throughout, for the summary slides, I put them up all at once while I was talking through them, so people had plenty of time to take photos of them for the Twitter, like so.
• I told people at the end of my talk that I'm bad at introducing myself but very much wanted to talk to more people, so they should come up to say hello. I also said I’d be identifiable over the next couple days with my blue hair and Veronica Mars and Harry Potter t-shirts. This ended up working out very well!

After the talk:

• I did the “hallway track” for the session after mine, i.e. skipped the next set of talks because I was too buzzed to pay attention anyway and tagged along with David to go talk to people here and there. It turns out even with people sitting around working on their laptops, there’s room to have at least some short conversations triggered by things like asking for stickers.
• I didn’t plan anything strenuous for that evening, just dinner at a not-loud place with a few people I already knew.

One thing that was cool was that early on, I’d asked for a show of hands of who in the audience had had to deal with time zone problems before and had made mistakes. It was something like 95% of the room! So I was reassured by an immediate sense of solidarity there. David noted that contrary to my worries that this was too simplistic a topic for anyone to want to come or have anything to learn from, it was actually just hard enough of a problem to have interesting twists around it but not too hard for the time allotted.

It was really, really, really nice to be done with my talk before the end of the first day. I had requested to be placed earlier on in the schedule when I confirmed my attendance, so I’ll definitely put that request in again for future talks I give. People came up to thank me at various points over the next couple days as I wandered throughout the conference, which was really rewarding (thank you to those folks for the thanks!). I’ve resolved to do this more myself for speakers whose talks I attend.

Finally, I did a good job for the rest of the conference of introducing myself to people here and there, like Hsing-Hui when I somehow recognized her hat and back of head when she sat a few rows in front of me at a talk. I’d planned to get lunch with Stella on Wednesday and then we picked up a few more women along the way for a nice little group to go out for pho. It almost gave the last day a bit of a “end of summer camp” feel as I’d wave to familiar people as I walked around.

For the next conferences, the two things I’d like to do better at are:

1. Pack my own snacks—snacks were hard to find and get at and there weren’t a lot of healthy options.
2. [edit] Discovered this in my notes—if I attend another speakers event, like the pre-conference speaker dinner, I should do a better job of stalking the other speakers ahead of time so I won’t regret the opportunity to speak with some of them before they’re mobbed after their talks that I attend.
3. Take more selfies with other people that have unnatural hair colors.

Like so:

This is not even that representative of all the other people who I talked to just because they had cool hair colors!

[edit] Oh I don’t know how I forgot, but I participated in the Opportunity Scholar/Guide program this year! I figure even with just the one year of attendance under my belt, I could maybe help someone out in navigating the conference to be less overwhelming. I found out I was accepted to be a Guide about a week before the conference and then was matched with Walter a few days later (everyone, say hi to Walter!) 

There was a mingling event the afternoon before the conference started and then I met up with Walter around once a day during the conference with breakfast together Wednesday morning and lunch on Thursday. They tried to reserve seats in the first couple rows of the big room for the Scholars/Guides during keynotes, which was nice (sometimes the “seats reserved” flyers didn’t get put out in time before seats were claimed, but it got better on later days).  Anyway, it was an easy thing to do, one more facilitated way to meet people, so if you’re attending next year and want to help welcome newer people, you should sign up!

Last note to self: log the time spent on each stage of building a talk for the next round.

Figuring out what to do for your Hackbright project

Even with it being two years since I graduated from Hackbright, it’s not hard for me to bring to mind the fairly constant low-level bewilderment I had for the first couple of weeks when it came to thinking about what kind of project I might do for the second half of the program. I’m not sure how useful this advice might be, but I’ve shared it with few people here and there so I thought it might be worth writing up how one might go about generating ideas for and deciding on The Project.

The tl;dr is: pick something new to learn, and pick something you’re a little scared of.

When I was going through Hackbright, Career Day loomed over us for many weeks. Our minds were so focused on getting there and having a demo for what felt like would be 7 minute tryouts with the partner companies there. However, afterwards, I realized as I was interviewing that going through a bootcamp is more about demonstrating your aptitude for learning a lot technical information very quickly. Companies hiring you are doing so based on your potential, and not as much on what your current level of knowledge is (or this is how I think it should be, anyway).

The way this all relates to The Project is unlike how I thought about it pre-Career Day, it’s not about having a polished demo by then. Instead, it’s about being able to talk about how much you learned. A common question I got throughout my interviews was “What was the hardest part of your project, and what did you do to get through it?”

So it should be an area where you can talk about how opaque it had been to you before, but now you’ve conquered. A good heuristic for this is a topic that you’re a bit intimidated by and therefore have to push yourself to get through it. When you succeed, though, you’ll have a pride in your accomplishment that will shine through when you’re talking about it to others.

And believe me, you will be talking about The Project over, and over, and over, and over again. For me it’s never been that useful to get advice like “work on things you’re passionate about!” because that makes me try to think of what kinds of things I sit around feeling excited about, but then I end up feeling like I’m not interested in anything at all, like I’m an incredibly boring person and I sit around feeling lukewarm about most things.

It’s the framing of “passion” that gets me stuck, though. If I think of it instead as things that I can talk about forever and my eyes still light up, or something I find myself obsessing over, or just excited to tell other people about—those are pretty good stand-ins.

When people ask me how I came up with the idea for my Hackbright project, the slightly sheepish short answer is that the lead instructor for my class, Christian, gave it to me. He handed me a C.S. paper to me to read and I thought it sounded like it would be cool to try to make what was described in the paper work. But to be fair to myself, before that, I had told him my two main criteria were that I wanted it to be hardware-related somehow, and that generally I was more interested in solving new problems than re-implementing things.

My interest in hardware came from thinking back to why I never considered studying computer science, despite having two engineer parents, despite never feeling intimidated in the slightest by science or math*, and despite attending a pre-engineering high school where we were exposed to computers and programming. And I realized it was because back then, I assumed that to be seriously into computers, you had to be someone that had been capable of building a computer from spare parts since you were 10.** So a hardware project suited me well on the “something new I want to learn that also kind of scares me” test.

The solving new problems thing is as contrasted to people that were interested in writing a compiler, or creating their new language (both of which were projects by my classmates!). For me, I would do something like that if I had as a class assignment, but otherwise my attitude is sort of like, other people have already done that and I’m sure they’ve done it really well, I’m happy to just use their work. Some people are really into diving deep into those topics, which is great! There are reams of literature on all the interesting complexities.

My project instead had just enough guidance out there for me to adapt certain tutorials for bits and pieces of it, yet nothing published about how to do it exactly that way from start to finish. I learned about halfway through that Christian had done it himself so he would reference his own implementation when I got stuck to give me guidance on where to go next. Successfully cobbling it all together and getting it working was incredibly satisfying.

The instructors are good at helping people scope out their projects for what’s doable within the timeframe before Career Day. Projects don’t have to be finished completely, and actually another question I frequently got was “what else do you want to do with your project?” so it’s useful to have some other stuff to talk about then. A few of us with some experience in product management made ourselves rough roadmaps of what our MVPs would look like and how that might map into the time remaining, so we could have a heads up of where we might need to redirect our focus with that Career Day demo in mind.

But I think pretty much no matter what, since you’re doing the work, you’ll have something to talk about, even if the work is unfinished by that particular deadline. Even failing demos aren’t that big deal, that actually would get people’s sympathies for demo-driven bug discovery, and it was a good sign if the partner companies turned to asking how I would approach trying to fix the problem.

I’ll also pass along the advice I received to ignore the urge to pick something related to the industry I was in prior to Hackbright. I had thought that maybe I should pick a project that used my domain knowledge there so that in interviews, I would be a stronger candidate in that industry. This might also manifest as picking a project because there’s a specific company you want to work at.

I think if you’re feeling that urge because you’re really drawn to that topic, it could work really well. Possibly, though, you might be doing that because it feels like a way to mitigate the risk you’re taking on in switching in careers, and if that’s the case, I think you should reconsider. You are probably leaving that field for a reason and probably aren’t all that interested in it intrinsically, so that topic might end up failing you when you have to talk about it for the 100th time. Better to have something that you can summon genuine enthusiasm for every time, because that will better catch interviewers’ attention, and better convince them you’ll be excited about your job there too.

Lastly, remember that this won’t be the last project you ever do. I remember the feeling that this was a pivotal, monumental decision, but freezing due to blowing up the decision’s importance wasn’t helpful. You’ll get to pursue at least some of the many different ideas you have, some day, and it’ll all work out ok in the end.

[edit 4/30/15] ah I forgot one more point I like to make with project ideas! Which is that when you're first developing tech project ideas, it's great to think about problems that you personally face but it can be hard to transition from thinking about what's interesting from the standpoint of content vs. the standpoint of interesting technical challenge. So a rough rule of thumb for this might be, would the interestingness of the project decrease if you had to fill it with fake data/content instead? Would it be a ton of work to generate that fake content? Note that it's totally ok to use other APIs, like maps, or scraping pages for content, but you want to look at it from the standpoint of, "this would still be interesting programming challenge even if the content served up were nonsense."

* I went to a couple “women in science!” in high school for fairly mercenary reasons, as my attitude was mostly “of course I can do science, why would that ever be in question, but ok cool if you want to give me some free stuff for it…” heh
** Also because I didn’t consider myself amongst the ones in our class that were particularly adept and/or obsessed with computers.

Slightly Less Painful Time Zones

This talk was presented in Atlanta at RailsConf 2015.

Abstract:
For developers, there are two things that are certain for time zones: you can’t avoid having to deal with them, and you will screw them up at some point. There are, however, some ways to mitigate the pain. This talk will discuss tactics for avoiding time zone mayhem, using a feature to send out weekly email reports in a customer’s local time zone as a case study. It will cover idiosyncrasies of how time zones are handled in Ruby and Rails, how to write tests to avoid false positives, and advice on how to release time zone-related code changes more safely.

Response to my talk, on Storify.

Testing checklist:

• covering time zones west/east of UTC
• pin down exactly when you’re starting and when you’re ending
• pick random dates in the past or in the future--not current dates
• test dates inside/outside daylight saving period
• check that the dates being used in your tests are the expected day of the week
• test when triggering the scripts on different days of the week
• test on dates of daylight saving transitions

Lessons:

1. Trust NOTHING
2. Have a backup plan
3. Do an internal test run
4. Today’s console results are not 
tomorrow’s console results 
5. Guard against writing false positive tests
6. Figure out a consistent, global logic

Code:

• local_1am method
• tests
• script setup

Notes from Confident Communicator course preview

Technically Speaking held their second webinar the other day, which was a preview of the Confident Communicator course from Femgineer. It was very informative and I'm hoping we'll be able to subscribe to the course through work. These are the notes I jotted down:

Finding a good topic to engage the audience:

• Need to get to know the audience better.
• 1. Talk to organizers to learn more about their attendees, then can tailor your content to that. Things like number of people, how corporate, what they’re interested in.
• 2. Send out survey to anticipate needs of audience. Seems like thinking on your feet, but have done a lot of homework. Or even can do a survey of hands at the beginning of talk. 
• How do you use info about the audience that you get last minute? Or if composition of audience not what you expected, or spread of skills is wide.
• Set expectations: quick overview for 5 minutes, then deep dive after 5 minutes for the advanced people. Even advanced people can still get something out of intro stuff. 
• Don’t want to dilute the talk too much.
• People feel, “why would anyone care about what I have to say?” especially if new to field
• There’s always someone who’s less experienced than you, they want to fast track their learning by hearing about your experience. What you wished you’d learned before you started, what you’d do differently if you did it all over again.
• Inventory method: take stock of recent projects (6-12 months). 5 questions:
• what problem were you solving
• what were you contributing to the projects
• what challenges did you face, any hurdles, places got stuck, created new process?
• what did you learn and how did you go about learning it? Books/websites/classes?
• what advice do you have for people faced with similar project, what did you wish you’d known? Like cautionary tales [note: this is exactly where I got my RailsConf talk idea from for this year! It's about this time zone feature I implemented and initially messed up on]

Building a good talk:

• Identify audience persona, what’s their motivation for attending talk
• Identify takeaways for audience, what do you want them to remember
• Anticipate audience needs—share stories with friends, get a sense of what their questions were, to work into the talk before they even have to ask
• Engagement higher when focused on problems that are universal
• Greet people as they’re coming in, ask them why they’re there, write it down. Shows you care, you know what’s important to them.

Handling difficult Q&A:

• Totally ok to not know the answer to a question! “I don’t know. Does anyone in the audience have an answer to that question?” 
• can be benefit, engage the audience, have them help teach the crowd
• Always repeat question — might end up understanding the question better. 
• You can say you don’t understand question and ask them to rephrase it. Other people might stand up and help rephrase, especially if accent is hard for you to understand

Links to resources for finding places to speak:

1. Technically Speaking Newsletter
2. Technical Women Speak, Too Google Group
3. WikiCFP
4. Call to speakers
5. CallbackWomen
6. Meetups in your area
7. Google alert for “lightning talk” or “unconference” or your favorite technical topic

Information about the course is available here, and you can purchase it here. There is a $200 discount for the first 10 people who sign up. For volume pricing discount email poornima@femgineer.com