Getting good feedback from practice talks

This is a collection of tips I've gathered over the last few years on how to get more from practice runs of a talk that you're working on. The first step, of course, is to run practices in the first place. These are optional extras on top of that.

Scheduling your practice

• I mostly run practices at work, so I'll book a conference room that fits around 10 people.
• In the calendar event, include the title and abstract for your talk, as well as any relevant details about the conference (when is it? what is the target audience like?) and target length of your talk.
• Select your practice audience based on people that you know to be supportive and skilled at giving constructive, kind feedback.
• Prior familiarity with your topic doesn't matter as much--maybe one or two people who could comment on "correctness", if that's something you're worried about, but getting feedback from people of "this part was confusing" is already very valuable.
• Invite ~3-8 people--enough for a spread of opinions and having at least a couple people that do show up.
• If your practice audience seems open to some coaching on giving feedback on practice talks, this old post of mine on giving feedback may be useful and this post by Lara Hogan on Giving Presentation Feedback in particular is excellent.

During the practice

• Turn on slide numbers in the footer of your slides, so that audience members can write down the slide number associated with the feedback they want to give. (instructions for Keynote)
• Thank your audience for coming and give them some context on the feedback you're looking for right now. I usually write down these points on a whiteboard in the room to remind them of what my focus is. 
• Could be: "overall flow and structure" or "do the technical explanations make sense for an audience of ____" or "physical or verbal tics" or "nitpicking on slides." 
• A sample set of questions from a friend who ran a practice talk:
• Are these helpful/interesting topics to cover?
• What else do you think would be helpful?
• Was the format understandable?
• Was the format entertaining?
• How could I add more funny pictures/entertain you more?
• Tell your audience what you aren't looking for feedback on right now (could be any of those items in the previous bullet too!) See this on the difference between asking for 30% vs. 90% feedback.
• If you're testing out timing, either set up your view so that you see a timer or ask someone in your audience to keep an eye on this. Recently when I was worried about the length of a particular talk, I asked someone to write down the times for each major section title as I hit it, so I could put those into my notes and see the breakdown overall.
• When you're ready to receive feedback, put your slides into light table mode and project that, to help your audience pick out which part of the talk they'd like to discuss.

• You don't have to make all or the exact changes that your audience suggests, but you should take the opportunity to ask questions and understand where they're coming from, in looking for improvements you can make.

After the practice

• Add their names to a thank you slide.
• Send the finished slides to the people who attended a practice talk, so they can feel gratified by the final, pretty version!

Wow Code, Such Read!

This talk was presented as a lightning talk at the New Relic afterparty for RailsConf 2016 and as a 30 minute talk at RubyConf Colombia in Medellín.

Abstract:
When we learn to code, that usually means learning how to *write* code. However in practice, we spend a lot of time *reading* code instead! It’s the way we find answers to questions about how things work. Reading code efficiently is therefore a very valuable skill. This talk will cover how Ruby developers can improve this skill, with tips for comprehending and debugging code faster. We'll also take a look at how you’d go one level deeper and read Ruby’s own source code, even if you don’t know much about C!


Slides:
Lightning talk slides:
Response to my talk, on Storify: lightning talk version, RubyConf Colombia.

Notes from webinar on creating inclusive presentations

Technically Speaking ran a webinar today with @judithmwilliams and co-hosted by @feministy on creating more inclusive presentations. Below is a writeup of my ~4.5 pages of handwritten notes from the webinar :)

• Judith's intro to the topic: did a lot of work on Google's unconscious bias training
• Know who your audience is
• out of a desire to connect, we tell stories, but that can then end up increasing the disconnect with the audience
• ex. speaker told a story about her triumph over blindness, but for visually impaired member of the audience, exhausting to hear her life articulate as the worst thing to ever happen to someone
• Imagine ways in which what you say might be received differently by people different from you
• Know yourself--know your biases
• we normalize our own experience, have a hard time imagining a different way
• proactively seek out other ways of knowing
• try to understand the stories that aren't being told
• What the goals of your presentation?
• might be to convey knowledge, but can dig deeper at your goals too--maybe to persuade?
• all stories have positive and negative manifestations in them--so you can reproduce or undermine common biases in stories
• think about who's included or excluded
• think about metaphors used in the story
• Recognize our limitations
• Can't be all things to everyone
• Be transparent about who is excluded and why, can highlight others better equipped for those stories
• Q: how to prepare a talk for an audience in a different country/culture from your own?
• You can ask conference organizers for a list of where people are from
• Make the presentation more accessible to everyone
• give handouts ahead of time
• Get people to be more physical, with low stakes ways to participate (raise hands, then raise hands higher, then have people stand up if they can relate)
• Giving speakers feedback
• "I think you had good intentions, but here's how this resonated for me"
• "Hey, that wasn't cool"
• Q: what to think about when prepping slides?
• Accessibility: consider those who can't see or can see very little
• videos: have captions
• images: describe verbally what's in them
• text should be big enough, high enough contrast
• (these are universal design principles anyway!)
• Use a variety of examples and photos: gender, ethnicities, ages, etc.
• are you reproducing inequities? are there patterns?
• show people of all different abilities
• ok to use aspirational photos of what you want your workplace to look like
• applies in writing too: pronoun usage
• Don't want ideas about inclusion to becomes weapons of exclusion
• Create a checklist for yourself, like the Bechdel test -- @judithmwilliams's version!
• Are you showing people that are different from you?
• Are you showing different people doing different things?
• Are you actively challenging biases and the mainstream narratives?
• Q: sources for images?
• Getty images
• search for "free"/"open source" + image you want, then check attribution
• ask individuals to be models in your own photos--don't have to use glossy stock photography! Don't be afraid to be unpolished
• Geography: try paying attention to how we talk about geography and spaces
• at Grace Hopper Conference last week, supposed to be for all women in tech, but lots of talks/data from North America -- rhetoric that tech only happens in San Francisco, not anywhere else, but then if it's in a developing countries, then given an award for it
• Discourses of safety => discourses of race and exclusion (some discussion around stereotypes people have of neighborhoods/countries that are "safe" or not, and people evaluating safety based on people's skin color in those areas
• Q: how to show people different from yourself but not get into cultural appropriation?
• In photos, if using them as examples of an idea--just an example
• When telling stories: whose story is it?
• ok to tell other people's stories!
• but do your research
• be honest about who you are, why this story, or this culture, for illustrating your point
• is it a convenient stereotype that we use vs. an illustrative story?
• surprising stories, that against the common narrative, are actually more interesting anyway!
• make sure you're not using a trope as an excuse
• Kind of like recruiting--diversify your network ahead of time, so don't have to default to an undiverse pool to draw from
• We could do a lot more for more age-based inclusiveness.
• Example: using an older woman programmer in your story, without having to comment about it
• Ask yourself: am I representing a different point of view?
• Q: how can you tell if you're being funny?
• see if your jokes land
• be careful who the joke is on

(I think they went on for a bit longer after this point but we needed to leave the meeting room I'd booked at work for us)

Continuing education at work (talk)

This talk was presented in Portland at PyDX 2015, in Detroit at self.conference 2016, and in Cincinnati at RubyConf 2016. I previously mentioned these continuing education programs in this blog post.

Quick links to resources:

• Book recommendations list
• Talk recommendations list
• Talk nomination form example (please make a copy)
• Stickers! Designed by the amazing Virginia Poltrack

Abstract:
The list of things we want to learn is infinite. How many of us have marked talks to watch, or books to read, yet have never gone back to them (until our browser crashes and we lose everything that was in an open tab)? Left to my own devices, I often only learn what I directly need in my work, despite the best of intentions. It wasn’t until I started running a couple lightweight continuing education programs at work that I followed through on my goals around continuing to expand my technical knowledge base. This talk will discuss setting up programs to finally get yourself reading those technical books and watching technical talks. We’ll discuss strategies for making these programs low maintenance and long-lived, as well as flexible enough to help both more and less experienced folks. If you’ve been looking for a more structured approach to self-education, this talk is for you!

RubyConf:
self.conference:
PyDX:

Response to my talk, on Storify: PyDX, self.conference, RubyConf

Appendix of painstakingly nitty gritty details I didn't include in the talk:

General items:

• How do you gauge initial interest in these kinds of learning groups? 
• Find ways to work it into conversation. When people ask you what's going on or what you're doing, say, "I'm considering starting a ___, what do you think? Would you be interested in participating?"

Logistics:

• Picking a day and time:
• Early in the week is good, not enough time to be pushed aside from pile of work to get done before the end of the week, have had the weekend to catch up on reading if needed. We have Technical Book Club on Mondays and LunchConf on Tuesdays.
• Time of day: not in morning, to have lunch time to do reading for book club.
• Weekly cadence is nice because you don’t have to question whether it’s an on or off week, but if every other week is needed, that’s ok too.
• Calendaring:
• Give everyone modifying rights to calendar event, to be able to add others (in general, have open editing permissions).
• Set up calendar events for yourself for any logistics items that need reminders, then don’t have to remember, get prompted by calendar notifications.
• Tracking: I started tracking attendance somewhat surreptitiously, just in case I need some data on participation to show management. But I haven't actually been asked for that yet.

More details on Technical Book Club:

• Book recommendations:
• We're keeping a running list of recommendations, trimmed regularly (like if the person who suggested the book isn't around anymore and none of us left have any interest in it)
• Solicit recommendations from larger office/engineering teams (also a way to publicize the group!)
• Voting on books:
• About 2 weeks before current book is slated to end, announce in various channels that next book is being decided upon.
• We review the choices, to remind people what each book is about and why we might want to read it.
• Then do runoff voting, everyone gets 3 votes in the first round (and can double up on one selection if they want), 2 votes in the second.
• Ordering books:
• If the book is written by an indie author and you have ties to the community, doesn't hurt to ask for a group discount! Authors seem delighted when people read their books as a part of a book club.
• Expensing: just because there isn't an official education budget doesn't mean there aren't funds to use, ask! Sometimes not an official budget because they don’t want to set a ceiling on what people think they can ask for, but on balance, books are very good value for the company when compared to sending people to classes and such.
• Reading assignments:
• Wrap up discussions with settling on next reading assignment.
• Don’t want to be stuck on the same book forever and need to feel like making forward progress each week, but not be hugely time consuming. Aim to finish the book within 2-3 months.
• ~30 pages or 1-2 chapters usually about right, depending on space taken up by sample code. It's about what people could get done in 1-2 hours.
• Post the assignment in the chat room and put it in the header--want to make it really easy for people to look up what the assignment is without having to ask someone else.
• Post a reminder the morning of book club on what the reading is.
• Also announce who agreed to facilitate the next meeting, so everyone knows and it's recorded.

More details on LunchConf:

• Have a form (example to make a copy of) for submitting talk nominations, from what people have seen themselves and thought was really good, or from blogs/Twitter.
• Minimum required fields: title, link to video
• Additional info: speaker name, talk abstract, length of talk (rounded to nearest minute, for easiest sorting), link to slides
• Include a link in the form description for how to view previously submitted nominations, so you don't get duplicates
• Calendaring:
• I have a room that's booked for an hour and a half. We always start 20 min after the hour to have time for A/V setup and people to get lunch, then 30-35 min talks, then a bit of time after for people to use the room to stay and whiteboard or discuss if they want to, but can also leave in time for 1pm meetings.
• Room booking and invite event are two separate calendar events, and attendees are only on the shorter event. That way, we don't get kicked out of the room, but it's not a scary looking 1.5 hour block on someone else's calendar, only mine.
• Choosing talks to vote on:
• Facilitator gets to pick 3 options.
• Good to try to pick a spread of topics so there’s a diversity of topics and appeal.
• If there are shorter talks, bundle a couple short ones together. 
• Voting:
• Initially counted votes manually (keep it simple), but then used the HipChat bot Polly. Now we do reaction voting in Slack, which is nice for allowing people to vote for multiple options rather than just one. The talks recommendation spreadsheet also has a copy of the generator I built for the Slack messages, making things easy by allowing you to just copy/paste to set up the voting.
• Announce which talk won in the chat room at least 30 min before people leave to get lunch, so they can decide whether to attend or not.
• Video playback tips:
• I use the youtube-dl command line tool for downloading videos from YouTube, that way won’t have streaming or connection issues
• Oftentimes there will be multiple videos you can play for a talk, try to pick the one that seems highest quality/most official. 
• If possible, check any comments on the video in case video is corrupted in some way. Be suspicious of a video that's shorter in length without an explicit description that it's actually a shorter version of the talk, versus a corrupted video of the same talk. (I'll note that this is the ONE exception to ever reading YouTube comments!)
• If you want to try playing the video at a faster speed, easiest way seems to be get Quicktime 7 and adjust the playback speed using the A/V controls panel (under the "Window" menu).
• I find we can go as fast as 1.25-1.5x, depending on speaker pace and density of topic. If the original talk is 50+ min though, then it's usually better to just play it over 2 weeks instead.
• After the talk is over, try to find the slides and share with the group, helps reinforce the topic. If possible, good to have slides handy even beforehand, in case the slides aren't easily visible on the video.

[Update] Great post from James Cheng about how he implemented LunchConf at his workplace as well! I especially like the tips on how to include remote teammates.

Ask vs. Guess Culture Communications

This talk was presented in Detroit at self.conference 2015, in Berlin at eurucamp 2015, in Chicago at Write/Speak/Code 2016, in Braga at RubyConf Portugal 2016, and in London at The Lead Developer UK 2017.

Abstract:

Have you ever been told you’re “too direct,” or feel like you don’t understand what others want? Or on the other side, do you think others are often too confrontational? These are Ask vs Guess Culture differences. Ask folks believe it’s ok to ask anything, because it’s ok to say no, while Guess folks prioritize not imposing on others. It’s a culture clash that isn’t often recognized, yet causes quite a bit of tension and frustration. This talk will cover the nuances of these different communication styles, as well as strategies for bridging the gap. Gaining an understanding of these differences and learning specific tactics for a professional context will make you a drastically more effective communicator.

eurucamp slides, Storify:

The Lead Developer UK: slides, Storify
RubyConf Portugal: slides, Storify
Write/Speak/Code: slides, Storify
self.conference: slides, Storify

This was the original ~9min lightning talk I gave at a company engineering offsite:

Advice for your first talk

I’m going through and clearing out very old blog post drafts. This is from a randomly long email I wrote to the Hackbright listserv of advice for someone giving their first talk, after I’d given my first talk How to be a Better Junior Developer at RailsConf last year. The main point I’d add to all this is that you don’t have to succeed at All The Public Speaking Things all at once, on your first few talks. It’s easy to get swallowed by all the information on public speaking out there, so if you’re getting too overwhelmed by it all, I think it’s more effective to ask yourself:

1. What do you want your audience to get out of your talk?
2. What do you want to get out of having given the talk?

For example, for my How to be a Better Junior Developer talk, the answers to these questions were essentially “get them thinking about all the non-traditional strengths they bring to a team” and “give a talk at a tech conference.” Then later I could know that I succeeded, since I’ve had lots of conversations with people about the former, and I didn’t literally die, so I succeeded at the latter as well!

One of the reasons I wasn’t super thrilled immediately after that talk was that I had some secret (even to myself!) goals that I was caring too much about, like wanting to be validated by getting the audience to laugh, or having a flawless delivery that matched up exactly with the script I’d written out. It would’ve been better to save those for future talks, not to mention explicitly stating them, which would let me see when they’d need to be adjusted to be more productive (no one else cares about how well it matches against my script).

For example, it’s a future goal of mine to be able to do the thing where you don’t need to refer to speaker notes at all and can just wander around out in front of the protection of the podium. But for my Slighty Less Painful Time Zones talk, my goal was to give a talk with code in it, with clear explanations and generalizable lessons for the audience. So it was ok that I still wanted to stay behind the safety of the podium and reference my speaker notes there.

Finally, related to all the above, getting better at public speaking is a continual quest. One of the reasons I started reading about improving at public speaking was that I figured this was one of those skills where no one would ever be like, "oh, so-and-so is too good at public speaking." There’s always room for improvement! To that end, these are the resources I use to learn more about how to improve:

• Observing what I like/dislike in other people’s talks (sometimes I get distracted by the meta-ness and have to remind myself to be paying attention to the content too, not just the delivery style)
• Reflecting after each talk to note to give future-me a list of what to do better next time (like after RailsConf 2014 and RailsConf 2015)
• The Eloquent Woman (blog)
• Technically Speaking (newsletter)
• Presentation Zen (blog, doesn't update that frequently)
• Femgineer’s Confident Communicator course looked excellent in the preview webinar I attended, hopefully I’ll get to take it some time!

Talk content:

• Once I knew I was going to give a talk, I kept a running doc of all the random ideas that came to mind that I thought I might want to fit in, other articles that came up that seemed like they'd be relevant, until I had enough of a mass of material that I could cut down to fit 30 minutes, vs. like with writing papers when I always felt like I was stretching to reach the word count.
• Write up at least your talk outline first, outside of making slides. Much more work to fiddle with slides later if the structure of your talk isn't pinned down yet.
• Sometimes I write out an exact script and practice it until I can do it off referencing bullet points or ideally no speaker notes at all, but that takes a lot of time. Practicing it out loud helps me realize which turns of phrase are fine in writing but sound awkward out loud, or that I have trouble remembering. I'm trying to become more flexible about this kind of thing though, so I think it depends on how much you would benefit from the extra structure.
• People love personal stories, make yourself relatable to evoke empathy and help people feel like they're getting more out of your talk. Basically you’re like, “I’ve been where you are, I understand you, here's how I got out and how you can do it too" and it gets received as, “I’m like this person, so what this person says is relevant to me...that was such a great talk!!"
• Asking rhetorical questions are an easy way to get "audience participation" without feeling like it's too much of a strain. I did a ton of, “Show of hands, how many people have felt this way before??" and raised up my own hand to get people to see that I expected a response.

Talk length:

• If you think about it, few people ever say, "man, I wish that speech was a lot longer." So it's better to hit 20 minutes and leave them wanting more, than going way over time allotted for a 30 minute talk to 40 minutes instead.
• Related to that, I’m always reminding myself to try to sloooooow dooooown. My default speaking speed is on the faster end of things, and when I get nervous on stage it can get jerkier and squeaky--not a very effective delivery mode for me. So adding in uncertainty for whether I can finish in the allotted time doesn’t help, and it’s better to think I can slow down as much as I want and not go over.
• Or, think about the talk as a series of mini-talks that you're stitching together. Might be less intimidating to pull together three 10-minute talks than one 30-minute talk?

Technical details:

• I used Keynote for the first time and loved it, if you have a Mac and can get access to it, it's definitely worth trying out because they basically set it up so that it's hard to make ugly slides. Could be worth seeing if you can expense it. (see this post I wrote on slide building tips)
• Look at a handful (but not too many) other speaker decks to get a general sense of designs/formats/structures that you like. Then just blatantly copy one of them and sub out for your own content--unless this is a talk about design, people won't really care that much about the slides themselves for you to spend enormous amounts of time on them. My slides, other random sets I liked. 

Dealing with nerves:

• Power pose
• Put a positive frame on the stress you feel
• Doing a handful of jumping jacks right beforehand (this way I can tell myself my elevated heart rate is due to exercise instead of nervousness)
• Whatever else you need for you, even (especially) if that means being completely anti-social and not talking to anyone beforehand
• Don't apologize for being new or not having a lot of time to prepare, but you can expose your vulnerability to get people on your side to root for you, if that works for you. So like, instead of "sorry this talk was kind of last minute...", you can say "I'm so excited to be here! I'm a little nervous though, so I'd really appreciate it if you all _____" (a friend of mine filled this in with "encouraged me by clapping whenever I get to a section title slide or take too long a pause" which worked really well for him, but he's also just kind of very charming and adorable)
• "How to Talk to Developers" by Ben Orenstein is good, ~30 min long. There's a really good set of practical tips around body language and such near the end, so stick with it.

Other:

• Practice practice practice. Don’t be shy, corral people you know to be guinea pigs and get feedback from them before the real thing. Practice at local meet ups, go to local code schools to be a guest speaker, etc.
• Practicing in front of the bathroom mirror is something I find helpful, because I know immediately if I'm making eye contact with myself.
• Including practicing taking breaks to drink water!
• Include practicing with a clicker, there are lots of remotes you can set up to use as a clicker. It lets you be a bit looser than if you’re tied to hitting an arrow button.
• You will probably forget to say something you planned on saying during your talk. Who cares! It's more important to convey your overall message and connect with the audience than to remember every detail of your planned talk.
• Relax and enjoy the experience; the audience will too! It is the most amazing adrenaline rush you're done and it's gone really well, so use those nerves to pump energy and enthusiasm into your talk.

Slide building tips

Kind of a grab bag of things I learned last year while building slide decks for my talks in Keynote. Keynote has a lot of really nice features and defaults to help you make a visually appealing set of slides even if you’re not a designer.

Keynote things:

• My favorite thing about Keynote is the ability to group slides together. It's really useful to be able to deal with sections of slides at a time by collapsing/uncollapsing, and you can even nest these groups for further sub-sections.

• You can also "Skip" slides to hide them from view without having to delete them...sometimes I'll put an Appendix section at the end for slides I'm not sure about and then I can Skip them all as a group to hide them from the printed PDF version for uploading to speakerdeck.
• There's a lot of power in customizing the master slide templates and doing so early on so that similar sets of slides (section headers, repeats of the agenda, etc.) can be updated in one fell swoop later on
• You can set text fields to be editable in order to have placeholders with the right styles applied, but being able to customize the content. I did this with the navigation breadcrumbs along the top of the slides in How To Be a Better Junior Developer
• Do a couple runthroughs where you click through your slides really quickly, which helps you notice mistakes in alignment/spacing that aren’t consistent
• If you want to practice on own computer w/o display and see speaker notes, choose “View > Rehearse Slideshow”
• I like the orientation of slides where the current slide is on the left, the next slide or action build is on the right, and your notes are on the bottom, as well as having the timer at the top:

Visuals:

• color.adobe.com for color schemes, use hex code converted into numbers to figure out what the RGB color equivalent is. Apparently you can also use Mac color palettes? I need to learn how to do this.
• Getting photos: search on flickr under Creative Commons 
• Icons: The Noun Project
• The font in my slides is all just Helvetica, altering between light and bold (but avoid Helvetica Light on a dark background, becomes hard to read).
• When it was bold, especially for headers I also set the letter spacing so that the letters would be a lot closer together, based on my designer friend's advice. See this example slide.
• Don't be afraid to move up text closer to header from the default in the template for better spacing

Uploading slides:

• To get a PDF to upload to something like Speaker Deck, “Export to PDF” instead of printing and saving to PDF; the latter leaves you with a white border above and below the slides
• As a viewer, I like it when people have detailed speaker notes with their uploaded slides because it’s faster for me to skim through those than to listen to the talk to see how much I might get out of it. As a speaker, it would take a fair amount of extra effort on top of what I already put into building the slides and practicing the talk to make the speaker notes readable and not embarrassing :) so as a result I’ve only just uploaded the slides, plus hypocritically, even though I don’t like watching videos that much, I kind of want other people to watch mine.

Putting code snippets on slides

[Update 5/17] This presentation has excellent advice on putting code on slides, with examples.

My Slightly Less Painful Time Zones talk was the first talk I’ve done that had code in it, so I learned some new things about making slides that have code on them.

Setting up the slides

According to trusted references, it’s best to go with a dark-on-light color scheme than a light-on-dark one you might work with normally. The reason for this is how projectors work, apparently? I didn’t test or question this too much but I’m happy to accept it as true.

When I first put together some draft slides, I just did quick screenshots of my code in the text editor. This become unwieldy pretty quickly; the inconsistent sizes of the images bothered me and it was annoying to have to take a new screenshot every time I noticed a small error or correction that I needed to make.

Then I learned about plugins that let you copy code with syntax highlighting in them! I found this SublimeHighlight plugin that lets you copy your code with its own specified color scheme independent of your actual Sublime theme. Pretty neat! The default color schemes available weren’t perfect when I tested them but I ran out of time to tweak the tool setup and did end up adjusting some of the colors directly in the slides. I decided I vastly preferred code as text on the slides, rather than images.

For console output, normally I use iTerm (to have numbered keyboard shortcuts to move between tabs), but it wouldn’t copy over output with RTF. The Terminal program does, though, so I just used that.

What to show on the slides

I had gone into the slide-making process thinking that I needed the code on the slides to prove I wasn’t making up the stuff I was talking about, so it was kind of a defensive attitude at first. After a practice run, my talk mentor Jason made this excellent point:

Code slides are generally primarily meant to convey information and are not meant to be code that can be immediately downloaded as is to be run. 

So a better approach is to figure out what’s actually important to highlight for the points of discussion in that section of the talk and only show those pieces of code on the slide.

Thinking back to my own experiences, there’s a fairly low limit to how much code on one slide that people can absorb, so removing some of the extraneous stuff needed for setup or breaking things down into smaller pieces by using helper methods (that you don’t actually have to show) is totally fine. Other tactics include showing the whole block of code at once, fade out, then highlight the code line by line again to review.

The main way I ended up doing it was judging based on each slide whether I wanted to build it line-by-line (often useful for console output) or if there were certain sections that I’d just build as a paragraph group together to go with an explanation like “these lines do __this one thing__.” If you peruse the slides, you should be able to get a rough sense of this since I exported the PDF to have the different slide builds all in there.

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.

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

Technically Speaking webinar: Public Speaking Scares Me, Should I Do it Anyway

My notes from the Technically Speaking webinar hosted by Cate, Chiu-Ki, and Denise. Even though I've followed each woman's work for awhile now, it was 1, still packed with new-to-me advice and 2, really fun to hear all of their accents and stories together! Here is a Storify that Cate put together of the event too, and here's a follow up piece the trio wrote about managing fears at different stages of the talk process (includes a video of the webinar!).

The format was pretty loose, Denise opened up with an overview of common fears of public speaking that people have, and then Cate/Chiu-Ki started pitching her questions polled from the audience through the Google Hangout setup. I imagine it's somewhat tough to do something like host a webinar where lots of people are listening in but you don't really get audio or visual feedback from an audience, but they handled it well. Anyway, I tried to re-organize my notes based on the broader themes that they hit upon since a lot of the questions had common themes.

Fear of public speaking

• Break out different kinds of fear
• to produce anxiety in research studies, psychologist spring impromptu public speaking tasks on their subjects -- so reliable for producing anxiety
• counteract physical effects of anxiety with smiling
• Aggressive challenges from people are to get women to sit down and be quiet -- don't silence yourself, they've already won. Giving away power by believing you don't have any.
• Fear of what happens being worse than what happens itself
• Technical talks: almost more factual, not directly confronting people's opinion, but through your action in being up on the stage and talking
• It is rational to make choices to avoid harassment. Find a rational reason for taking the risk. 
• Reasons to speak: covered travel. Makes travel decisions for you. Establish yourself as an expert for freelance contracts, future jobs. Helps your opinions later on be weighted more heavily, because you have a "presence"
• If it's a friend with anxiety, don't correct her/his feelings. Maybe suggest coaching (Denise! She's so insightful.) or recommend a woman as a speaker

Preparing for a talk

• Having opinions is important, talks are poorer and more boring without them
• Pick a time in advance of talk to freeze it
• Save new ideas for another talk, can't get it all in anyway
• Schedule a practice at a meetup and have your talk "done" for that time, prior to conference. Can still edit a bit, but mostly done
• Junior developer feels like can't teach more experienced people: your perspective is still unique.
• Also not your job to determine if talk will be interesting to audience through proposal, that's conference organizer. Work really hard on talks you know you're giving, don't have to expend as much effort in early stage of proposal writing
• Introvert: advantage in planning and preparing for the talk, even if not drawing energy from audience in the delivering of the talk
• Find a place to be absolutely alone before the talk, like a stairwell. Conference organizers aren't always great at setting this up, but you can figure it out and make it happen for yourself.

Handling Q&A

• Giving a talk is not a test. You don't have to be the expert, but a expert. Sometimes people are just curious to find out whether you know and won't hold it against you if the answer is no.
• You own the stage. No obligation to answer questions. Could just not leave time for Q&A. (the hosts agreed to disagree on whether to do it)
• Some people are just asking questions to hear themselves, maybe hearing themselves challenge you.
• Cultivate not being anxious when people disagree with you -- not every question is a challenge
• Come up with 5 great ways to say "I don't know" and practice them!
• Open up/deflect to someone else in the audience ("That's a great question. I haven't considered that angle before, is there anyone in the audience that might want to speak to it?")
• Gather questions at beginning, then give talk, then answers later. Letting the questions air early.
• Dealing with hecklers
• "Tell me why you asked the question in that way?" if tone seems aggressive
• "Aw, there you go again!" gives you power back in calling out people that might be repeatedly challenging you (Reagan tactic)
• "Thank you for sharing that." & move on, don't have to agree with them

Some quick thoughts on talk proposals

If you have a talk proposal that's a bit more technology-agnostic, and/or you want a bit of a niche audience, submit to the bigger conferences in the different languages (your PyCons, RailsConfs). I think you'd have a better chance of being accepted that way.

For example, I didn't bother submitting my “How to be a Better Junior Developer” talk proposal to RubyConf, since there's probably a lot of overlap between attendees there and RailsConf, both being in Chicago and in the Ruby/Rails world.

Don't put pressure yourself to come up with a totally original idea, or on a technical topic, if those aren't the ideas you have right now. I've found a lot of other programmers that are also very interested in the intricacies of communication and psychology. Also, it turns out that the beauty of giving a talk on communication is that the people that come up to you afterwards are pretty much all into the topic. Because after all, the people who disdain the topic are probably not great communicators themselves, and poor communicators don't communicate :)

I think in a way, it might be slightly easier to get a talk accepted at a big conference, since there's a wider variety of interests in the attendees. The small regional conference feels a lot more manageable though, and an unforeseen benefit to me is that if you speak there, you become more known to the more prominent members of the community that are also speaking there since they're sitting through all the talks at the conference.

Adapting a previously-given talk

After I gave my talk “How to Be a Better Junior Developer” at RailsConf and wasn't totally happy with how I delivered it, I was determined to get some more out of the hours upon hours I'd put into pulling that talk together. I took pretty much the same proposal that I'd written for that talk and submitted it a whole bunch of other CFPs.

It got rejected from most places—most conferences are smaller than RailsConf and having a talk so directed at junior developers might be too small a proportion of their audience, I think. I then added on to the talk proposal description that if that was a concern of the organizers, I'd gotten feedback even from senior developers* that they thought much of the content could be more widely applicable and I'd be happy to work on making the talk to be directed at a broader audience if they thought that would be more appealing to their particular attendees.

The talk actually got accepted as-is to PyCon Au, which I was really thrilled about! I studied abroad for a semester at the University of Melbourne and loved it there, but couldn't afford to travel much (in particular, it is a life goal of mine to see Uluru). Unfortunately the timing didn't work out, so maybe some other time.

Of the rejections I got, I was able to get extra feedback from eurucamp. They said they weren't able to really tell what was going to be in the talk, because I'd spent more time in the application talking more about how I could adapt it. I had included a link to my blog post and slides about the talk in its current form, so I'm not sure if they didn't visit that or thought it was insufficient, but I was more careful after that to make sure to still have a fully fleshed out talk proposal so conference organizers wouldn't have to leave the application to get all the info.

This “hey I can adapt the talk if you want” strategy then ended up working out with ArrrrCamp. The organizers actually wrote back to me something along the lines of, “it was between this talk and another one but we think this one works better, if you can adapt it."  I quickly wrote up a new title and abstract and then after buying the tickets for my flights, just set a reminder on my calendar to get back to the talk about 2 months before the actual conference. Which meant of course, I did most of the work the day before the conference.

But the reminder actually still worked, because in the time I had “adapt talk for ArrrrCamp” on my to-do list, I was at least doing some background processing in my brain for what changes I needed to make. I talked a New Relic intern** into helping me with a practice run-through, hoping that would motivate me to get the work done sooner, but that didn't quite work out with the other things I'd had going on that week. Still, going through the talk out loud with another person helped me get some notes on which sections should be cut, and I also asked her to give me feedback specifically on which sections she thought would resonate even with a wider audience.

I realized that I needed to re-work the structure a bit, but I still wanted some kind of overall organizing outline like I'd originally had with the two overall sections with 3 points each, since I thought that helped make the points easier for people to remember. It was too inefficient to try to change the slides first, so instead, I just pulled up a text file and thought through which of the main points I'd want to keep and how I might be able to group them together a little differently. Much less work to move around the different lines of the outline then.

I came up with two new broad themes, around building relationships and improving communication skills. Into each of these, I slotted the other sections I'd had before. I consolidated all the advice around mentoring and being mentored and put them into its own section. However, I ended up ripping out this section entirely because I figured my audience wouldn't necessarily all care about mentoring and the argument for how being a better mentor would help them was a bit more loose. If people did care, there are other talks out there entirely focused on mentoring they could turn to.

Instead, I replaced it with a slightly stripped down version of the “Ask vs. Guess Cultures” talk that I gave at the New Relic engineering offsite earlier this year. That talk had gotten a GREAT response, with lots of people telling me they'd never heard of that concept before but learning a lot from all the stories I told***. I figured that since I had material that'd been shown to be novel, funny, and apparently useful to a similar audience, that would be a good bet.

Once I'd gotten the slides moved around and the speaker notes edited and everything cleaned up with the new outline, I ran through it a few times just speaking out loud to myself in my hotel room. Ideally I would have liked to be able to practice out loud in front of other humans, but this was like 11:30pm the night before. Not great, but still early enough that I'd get a decent amount of sleep. At least most of the different components making up the talk had been given in front of people at some point.

And it all ended up working out really well! For future talks, I'm going to keep in mind Cate Huston's technique of a grid system for the different points in a talk so it's possible to see at a glance how you can adapt it for different lengths.

*ok fine, secretly I always thought that that was true, but 1, I'm particularly interested in helping other non-traditional background developers like me, and 2, it seemed kind of presumptuous to state something like that myself while I'm still a pretty junior developer.
**I had to find an intern because most people at New Relic had already listened to the talk at least once when I was practicing for RailsConf, lol.
***Particularly the stories involving my husband, which got really big laughs, even with a non-American audience. Apparently I'm pretty talented at telling funny stories involving my husband, which is something I'm keeping in mind for future talks, haha. As another ArrrrCamp attendee told me later, my husband might become my Gorbypuff (that's Aaron Patterson's cat that he talks about on Twitter and passes out stickers to make it easier to talk to people, lol).

Reflecting on my talk at ArrrrCamp

The talk I gave at ArrrrCamp was essentially my “How to be a Better Junior Developer” talk but adapted to be more generally about getting better at the non-technical aspects of working as a developer. I'll have a post up at some point about how I did that adaption, but first I went to reflect on how it went, which was…really well!!!

Here are some of the things that I think I had going for me or did well at:

Giving myself permission to be anti-social before the talk
I didn't exactly reread my own blog post about what I was going to do better next time after I gave that talk at RailsConf but the key thing I remembered was how terrible it was to not have gone to sleep the night before until 3am. I went out in the afternoon to do a bit of sightseeing and find the venue so I'd know how to get there from the hotel, and that was enough. There was an informal meetup of ArrrrCamp attendees at 8pm the night before the conference started, but I decided to skip it because I knew that if I went, I might tire my voice out again, and then be up ridiculously late doing another practice after getting back. Better to just work on it and go to bed after one out-loud run-through, then getting up early to have plenty of time for a quiet breakfast and another run-through.

Also, a really cool thing about ArrrrCamp is that the breaks between talks is scheduled to be a whole 30 minutes! I considered shutting myself into a quiet corner for these before my talk, especially the break immediately before. I did this at the engineering offsite, I went to the room where the luggage was being kept and just lay down listening to the sound of birds chirping outside for awhile, and that helped me feel a lot more refreshed and ready to tackle giving the talk. I didn't end up going that far for ArrrrCamp, but I did tell myself it was ok not to make much of an effort to introduce myself to new people, even though an overall goal I had for the conference was to have a lot of good conversations with new people. I did end up talking to a couple people, but it was just one-on-one and very manageable.

Where I was on the schedule
I had the PERFECT spot on the schedule, being the third speaker on the first of two days. I didn't have to go first, nor did I have to go second and worry about it all through the first speaker's talk. I also didn't have to go right before lunch was going to be served, but I got the talk over and done with and didn't have to worry about it for the rest of the conference and could pay better attention.

The venue
I was really happy with the flow of the talk, compared to when I delivered it at RailsConf. The venue for ArrrrCamp was essentially like a lecture hall theater, but the lighting was very friendly so that at least in the beginning, I was still able to see people's faces instead of looking out over a sea of darkness and shadow. I was even able to grab a photo of the audience from my perspective as a speaker.

The conference being single-track
Also, I think I liked giving a talk at a single track conference better. With a single track conference, the number of attendees pretty well closely matches with the capacity of the venue, so people were sitting a bit more packed in than the room I had at RailsConf. At a bigger track conference, it must be hard for the organizers to predict which talks will need more seats, and as Ben Orenstein mentioned in "How to Talk to Developers", you would always rather have a packed small room than a cavernous large room for your talk, even if the number of people is exactly the same.

I have a theory now that getting people to sit closer together in your audience helps them be more engaged in the talk, particularly if you have bits where you want people to laugh, since that's such a social thing. You don't see any standup comedy clubs where the audience members are really spread out and far from each other, right? Everyone was really packed in tightly at the engineering offsite where I originally gave the Ask vs. Guess cultures talk, and laughter would swell up around the whole room in like a big wave.

The other nice thing about the conference being single-track is that I didn't end up feeling competitive or anxious about people wanting to go to the other talks. People pretty much had to come to my talk, and if they stepped out, I could assume it was because they had some work they needed to do or something, not because I was boring them that badly.

Dealing with my nervousness
As before, I reminded myself that the feeling of wanting to puke right before I was supposed to start was totally normal and just a sign of overexcitement, not a sign that I was going to do horribly. This seemed to be a bit more effective, despite not having done a ton of practice talks of the new version of the talk. Maybe because I was more confident in the Ask vs. Guess Cultures segment I'd swapped in?

I also tweeted about that about-to-puke feeling because I've decided that's something I can do to help encourage other people. Showing vulnerability is good, I think, and I loved these statements from Aaron Patterson:

Getting ready to speak at Arrrrcamp. #nervous http://t.co/UzDfFEuJeP
— Aaron Patterson (@tenderlove) October 3, 2014

"I was really hoping no one would show up this morning because I'm scared. We could just go get coffee & pretend this happened" @tenderlove
— KWu (@kwugirl) October 3, 2014

"I'm a core Ruby & Rails contributor...which doesn't mean I know what I'm talking about, it just means I'm bad at saying no" --@tenderlove
— KWu (@kwugirl) October 3, 2014

Aaron seems to be kind of known for regularly needing to get through his stage by telling jokes for awhile before he gets to the main content of his talk. I talked to another speaker who's a bit like that, Piotr, who said when he's giving talks, some times things just come out that the audience apparently finds really funny but he doesn't realize until later what the joke he was making was. Like being in a comedian fugue or something, haha.

I don't think I'm the type to just spout out good jokes while feeling nervous, but I think I can do well with funny stories if I've practiced them a bit and have figured out the right rhythms for where to put the beats. I did let off a bit of the nervous energy steam with a few random quips, like subbing an example of my introvertedness about how I was trying not to make eye contact with people at breakfast. I think that worked well enough.

I definitely still talked a bit too fast at the beginning. I kept reminding myself to slow down, for the usual reasons of coming across as more competent and confident, but also because that might help this audience understand it better, composed as it was of largely non-native English speakers*.

Lastly, for this talk, I also gave myself permission to just stay behind the podium and close to my notes, rather than pushing too far out of my comfort zone just yet. Michael Ries (who was also the first speaker!) did an amazing job of this, he was in front out from behind the podium the entire time on his talk and it was still extremely smooth. I'm not sure if I'm ready for that yet, but I talked to him a bit about his preparation strategy. Here's what he said:

• this was only his second talk, but he'd started preparing it from the beginning with the goal of not needing to reference notes
• he still wrote a script that he would read through and try to memorize
• but then he practiced in front of people without that script, which helped him discover the places that needed work based on people's reactions and amend the script to discover the flow and beats to the stories
• also helped him find the places where the storyline needed to be improved so that he himself could remember where it was going next, maybe add in another slide to help serve as a trigger for him, hopefully with still having mostly slides that are designed with the audience's needs in mind vs. his own

Getting feedback
One thing that occurred to me after my last talk is that receiving positive feedback can be an opportunity to do some market research, as it were. The positive compliments I've gotten usually are something like, “I really enjoyed your talk!” or “Great talk, nice job!” I try to be good about accepting compliments with at least a simple “Thanks!” as opposed to deflecting it or going into self-deprecation. In addition to that however, it's an interesting exercise to try to then ask, “Was there anything in particular that was new or interesting to you?” to see what particular sections might have resonated.

In practice, asking this could sometimes be a bit awkward, so I tried to soften it by saying something like, “you don't have to have an answer or anything, I've just been curious to see what might be good for me to focus on in particular for my future talks,” which helped a bit. One guy wasn't quite sure at first, but then actually came up to me the next day and told me he had a better answer now and gave me something more specific, which was really awesome.

In general, the responses I got were mostly on the Ask vs. Guess Cultures section, the section on remembering to express your appreciation to people who've helped you, and generally on the idea that communication can really help a team be more effective. Some people even said something like, “I can't wait for the video of this talk to be posted so I can make everyone on my team watch it,” which of course is immensely gratifying for me to hear.

So, goals for next time:

• give a talk with code (I have one talk proposal about time zones written up that got rejected by RubyConf, but I'll submit it to other conferences that are more Rails-focused, and a couple other ideas I might write up proposals for)
• feel freer to move from the podium—not sure if I'm ready to leave the podium behind entirely, but I can try to practice with that a bit more in mind. A compromise might be like how some speakers step to the back and side of the podium a bit, so that there's more movement, without getting that feeling like you're exposed in front of a large crowd that might eat you.
• as part of that, remember to get set up with the clicker, I forgot this time around even though they had one
• write up post-it notes to stick my laptop to remind myself to slow down. I always do this when I'm doing interviews over videoconference, so it might help when presenting too.
• tell people at the end that I loooove for them to come up and introduce themselves, because I always feel awkward doing it myself
• maybe tell people at the beginning that I should have time for Q&A at the end so they can write down questions that come up during the talk?

*It boggles my mind that people can learn additional languages late enough that they have an accent (so, not as children) but do well enough to actually work in that language. The idea of attending a conference that's entirely in Chinese makes me feel really tired…I should probably do that at some point if I can.

Be a Better Developer (no code required)

This talk was presented in Ghent, Belgium at ArrrrCamp 2014 and is an adaption of my How to be a Better Junior Developer and Ask vs. Guess Cultures talks.

Abstract:
Most developers focus on increasing their technical knowledge. However, there are many aspects to working as a professional developer besides coding proficiency. If you have interests or experience in other fields, you can pull in even those non-technical skills (like building relationships, project management) and immediately increase your impact on a project or team. When you mentor someone, you can help them play to their strengths and ramp up more quickly as a result.


 Response to my talk, on Storify.