Notes from Sandi Metz fireside chat with Women Who Code

The absolute highlight of my trip to RailsConf this year was an event put on by Women Who Code featuring Sandi Metz! Sandi is a widely respected teacher and consultant in the Ruby community. She really focuses on clear explanations and her talks are set up so that people at all experience levels can get something out of them. And as it turns out, she also has great insights to share about making technical decisions, getting up the courage to start giving talks, and so much more wisdom generally.

Below are my notes for the session, but WWC actually managed to record the whole thing too! It's an hour and 20 minutes long, but I might even watch it again myself, even though I was there (the person that's kind of loud and asking lots of questions? That was me!)

Anyway, I tried to clean up my notes and roughly rearrange them by general category.

Her own background:

• music student but then into votech school for data processing—this is fun story, you should listen to it
• no thought at the time (late 70s) that CS was only for men
• There are different types of programmers: she likes understanding the shape of the whole from the details, into abstraction
• great for her to partner with Katrina Owen because Katrina is the opposite, derives from the bottom up

Definition for simple code:

• “the inebriation test” — look at code you didn’t write, after you’ve had a few drinks
• if you’re really smart, will write simple code
• code that seems inevitable later actually required a lot of time to write
• sequence diagram on whiteboard first, figure out objects & message
• insist that things be simple—refuse to write complex code
• leaned Object-Oriented (OO) by writing OO code
• hadn’t read literature on it
• there are easier ways to learn this: Steve Freeman & Price - Java & testing book, GOOS
• Rebecca Wirfs-Borck — single responsibility design
• Eric Evans Domain-driven design (PDF short version)

TDD

• already done design work
• TDD easy when you know a lot of design
• sequence diagrams helpful because then rest is implementation detail, don’t have to worry about writing code that you get attached to
• TDD: sucked at beginning, now vastly improved code, always find bugs
• don’t remember how small objects work, but ok, have tests
• tests of the right kind, don’t test everything
• believed in people who said TDD was a good idea (they’re lying or otherwise not good enough yet) — bosses would’ve said “good enough” without it

Monoliths vs SOA:

• lots of revolving door software — don’t have to deal with consequences
• but in real world, app will live a long time, app gets bigger
• the next shiny thing, not Rails, is coming
• want to be able to change part of your app to newest thing, without having to port over your entire app
• big monolithic apps hard to change -> go out of business
• breaking up large app without OO into services — will fail
• need to isolate bits of app into objects
• “find the seams” — then extract into another app
• network latency is a problem, but want to get there
• edges with clear APIs

Preview of her RailsConf 2015 talk:

• if is always with an else
• even if about that thing, it’s a specialization of that’s also a thing
• missing code
• objects to embody holes in your code
• yin & yang if you have a thing, then model the absence of something. just as real as a thing, need it for good OO design.
• “nothing is something” null object pattern
• like inventing zero, just as real as everything else (this analogy was actually a question from me, that then got a shoutout in Sandi's newsletter! I'm still a little giddy about that!)
• biologically wired to be good at people names
• yield the block (true) vs ignore the block (false)
• if/else without conditionals
• true - true yield the block
• false - true ignore the block

Writing books:

• nobody would read POODR while it was being written, hated writing
• finding a voice — writing is hard enough without owning your voice, so do it, bend it there
• couldn’t do academic tone
• well just going to be goofy, didn’t want to write book anyway
• new book: 99 bottles, first 2 days of course — join this mailing list!

Coming up with talk ideas:

• your perfect audience: the you that didn’t know what you know now. past you would be very sympathetic, very grateful
• don’t keep from doing things because of people who know more
• create content for people who know less
• people better than you—motivating to learn, strive
• there’s someone out there who needs you!
• judge yourself against the right people
• looking at people’s talks — she’ll help people in Hangouts
• there’s science about performing under stress like public speaking (“Choke” book)
• everyone is terrified the first time, no way to know if you’ll get over it until you try it
• don’t judge based on talks at work
• don’t decide in advance you can’t do it
• “good enough as an explainer & slide-maker” to get across idea
• “praise is great but unhelpful” — how to improve?

Making technical decisions:

• I know I’ll be wrong, don’t have enough data
• choose the errors that are the easiest to recover from
• learn to make many small things
• then fix it later, err on side of small until you know it’s too small
• bet that you’re wrong
• DRY — deciding that 2 things are the same, adding in an abstraction
• much easier to deal with duplication
• easy to fix problem of finding duplicates
• going from 2 (duplicate) -> 3, might decide you have enough information now
• but if you know there’ll be 4, duplication for the 3rd item, wait for #4
• hard to recover from bad abstraction

Other topics:

• career advice: commitment to learning over writing 80 hours of code a week — that feels like it’s truth as dominant culture, but only inside the cave
• functional programming — immutability, no side effects
• can write function OO code
• book: functional programming for OO programmer
• create subdirectory namespace under ActiveRecord for models
• things in model can be plain old Ruby object, to manage business logic
• not have concerns in Activerecord, AR just for managing database
• drive edges of framework apart
• make AR not the center of the universe
• naming things:
• use local experts on names, or else have a time box on deciding on names. make a best name you can change later if needed
• what story will these names tell to the next person
• care about the names
• “not the last book you’ll read”
• you have a right to be here
• have to help each other believe
• if you’re somewhere invalidating, get outside support or leave
• can’t fix everything

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.

Guide for newbie tech conference attendees

Now that I've been to two different multi-day conferences (and having made mistakes in how I approached them), I thought I'd pull together some tips for trying to get the most out of attending your first conference without getting completely overwhelmed.

0. Think a little bit about what your goal for the conference is, so that you have a heuristic for deciding what you want to do. Is it to learn a lot about a particular kind of technology? Is it meeting new people? For example, there were a few different informal socializing events at ArrrrCamp after the first day of the conference. One of those was rock climbing, which I was interested in trying out for its own sake, but my actual goal for the conference really was to meet people and have good conversations (while not getting overwhelmed like I did at RailsConf). So instead, I signed up for the bowling event. When the time actually came to it, my jetlag was hitting me pretty badly and I didn't want to go to an event where I might feel obligated to stay longer than I could really get myself to stay awake, so I instead went on the photo walk around the city where I could both easily chat up different people and leave early if I was about to fall over.

1. If there are any offers of some kind of conference guide program or attendee matchmaking program, sign up for it!! RailsConf had repeated messages about their program, but I didn't take them up on it because I thought I was taking up enough of their resources already from the support they were giving me as a first-time speaker, and I figured it was really more for solo first-time attendees. I also figured I'd be able to rely on my co-workers that were also attending. My co-workers really tried, but I ended up feeling bad about constantly asking to tag along with them and would then lose track of them. The accounts I heard of the guide program seemed pretty positive.

2. If there are specific people that you want to meet, take the initiative (probably over Twitter) to try scheduling breakfast/lunch/coffee/dinner dates or what-have-you instead of hoping to bump into them at one of the happy hours. I keep re-learning the fact that I dislike trying to get to know people in the loud and crowded environment of most happy hours. When instead I did things like reconnect with an old middle school friend over lunch at Portillo's, that was immensely more fun and effective.

3. Attend the lightning talks! I so regret not seeing Liana Leahy's rendition of “Let Me Code” (sung to “Let Me Go” from Frozen) in person. Anyway, lightning talks seem to be pretty reliably high value for your time, since the talks that are boring tend to be boring because there hasn't been enough editing to cut out irrelevant content.

4. Attend any smaller events you might hear about going on. Joanne gave me a tip about a thoughtbot podcast that was going to be recorded there one afternoon where Ben Orenstein interviewed Aaron Patterson, which ended up being in a fairly small room but was really cool to be in on.

5. However, IT IS OK TO SKIP EVENTS. I might've gotten more out of some talks if I'd gone to fewer overall or left some talks early after it looked like I wasn't going to get much out of them.

6. Along that theme, it's really important to take care of yourself. One of the best decisions I made during RailsConf was to sleep in the morning after my talk and spend the morning catching up and messing around on Twitter instead of going to see the keynote for that day (which was apparently quite funny, but I didn't think it would as important for me to see vs. DHH/Yehuda/Aaron Patterson etc.). I felt so much better about life, and then the first talk I did go see that day was Sandi Metz's, which was amazing already but particularly inspiring because I wasn't desperately exhausted anymore. At ArrrrCamp, I let myself sit alone and skip out on some of the socializing breaks in the afternoon of day 1 because it seemed like it would take more energy than I had left to get out of my seat to go talk to people (I promised myself I'd be better about it the next day, after getting a full night of sleep).

6a. Bring/eat more snacks. I get hangry pretty easily and the conference (being around so many people, attending all these talks I'm trying to pay close attention to, etc.) sucks up a lot of energy, so it would help to compensate for that with more snack consumption.

6b. Sleep more. Probably still won't get normal hours of sleep from being overstimulated, but just aim for as much as you can so you're not knocked off too much from your normal rhythm.

6c. There really are a lot of men around at tech conferences. It's always a bit overwhelming. My method for dealing with it is to let myself take a moment to acknowledge it before diving in to mingle or whatever.

7. I tried to take notes during all the talks I attended but I'd also come up with all sorts of ideas while sitting on talks (like new talk proposal ideas, things to dig into further afterwards, etc). I had a hard time re-finding those notes since I wasn't really taking notes on the talks to go through them again afterwards, but this got easier once I developed a different system for those notes to myself that I wanted to find again. I took notes on a reporter-style spiral notepad and put all my talk-notes on one side of the pages and all my notes-to-self on the other side so that I could flip backwards through and catch all the pages that had the notes I wanted to find again. Putting those notes aside in a draft email also worked.

8. Everyone talked so much about how the “hallway track” (general mingling and meeting new people in the hallways, outside of the talks themselves) would be the best part of the conference but I had a lot of trouble with this at RailsConf. A lot of people were on their laptops, so despite a co-worker's advice to just go up to people and ask them what they were working on, I couldn't bring myself to do that because it felt like I'd be interrupting them and I was afraid they'd be really annoyed about it. Instead, what worked a lot better for me was introducing myself to people that I sat near, before the beginning of the talk. That was a lot more similar to starting up conversations with strangers on public transit with random comments or observations, so I felt more comfortable with that.

8a. Another tactic to try is to bring your fandom or nerdy joke t-shirts to wear. This worked well for me when I wore my Veronica Mars t-shirt on day 2 of AdaCamp earlier this year, since that broadcast a potential shared area of interest to get a conversation going about.

9. When you tweet about the conference, using the hashtag instead of the official conference account handle so that others at the conference will pick up on the hashtag without the official account needing to retweet it.

10. Wear clothes that have pockets in order to not have to lug a bag around, or at most just have a light tote bag for my notepad and pen.

11. I didn't end up handing out all that many business cards. For most people, exchanging Twitter handles was sufficient, so I needn't have packed my whole heavy box of business cards, just brought a few extras.

(Note added 12/8/14: I started numbering this list at 0 because I wrote the post with all the numbers manually, then wanted to go back and add in a first point without having to renumber the rest. So think lazy, more than cutesy programmer numbering logic, lol)

ArrrrCamp 2014

ArrrrCamp is an excellent conference. I was a little worried at first about traveling so far (4 hours PDX-ORD, 8 hours ORD-BRU) to a conference and that I would just be this random American in Belgium for the first time, but I really had a wonderful time. Thanks, Hannes and Joren.

I've decided that I really like the single-track small conference (~120 attendees?) and they did a lot of other things on top of that to try to facilitate people getting to know each other without going over the top. With single track, you're not worrying about whether you’re missing out on a better talk somewhere else. Also, the venue is such that there’s just the main lecture hall theater area, and then another lounge area that they set up with mostly just the tall cocktail tables, which I think helped encourage people to socialize rather than just be hacking away alone.

The 30 minute breaks between talks on the schedule meant it wasn't a big deal if someone ran over a bit, and it was long enough to be able to relax a bit and have good conversations with people. Just much easier to manage meeting new people overall.

Food for lunch was quite good, catered by the bistro next door. Good sandwiches with high quality ingredients, as well as soup.

The people there were very friendly and accommodating.

Omg it's Friday and we have @tenderlove opening our second day with a nice hug 💚💛💙💜 pic.twitter.com/vIiMYDLK7z
— ArrrrCamp Belgium (@arrrrcamp) October 3, 2014

One of their traditions is a cocktail hour on the Friday afternoon but at that point, I knew if I had any alcohol, I was going to just fall asleep immediately. Someone suggested asking for non-alcoholic cocktails and they immediately mixed one up for me:

(Hannes even apologized for not having non-alcoholic drinks already available! Very sweet)

I’m pretty sure the ratio of female:male speakers was much higher than the ratio for attendees, heh. I did notice that the speakers were generally quite good about trying to be balanced in the examples they used (“Mallory the hacker,” “Alice vs. Bob” sample players in a game). There were several people affiliated with RailsGirls there, and there was a RailsGirls hackathon with dinner that had quite a few people attend. A lot of the women I talked were more junior like myself, but not all of them. Lena delivered a really well-done talk about diversity and inclusivity in the open source community.

Talk recommendations:

• Piotr Szotkowski, "Weak References Strongly Held" for a hilarious tour through the Ruby standard library using cowsay
• TJ Schuck, "80,000 Plaintext Passwords: An Open Source Love Story in Three Acts" with a clever use of a plaintext password list he had for a password conversion project
• Michael Ries, "How I Accidentally Wrote the Best Code of my Career" for his presentation style
• Aaron Patterson on improvements they've been making on reducing objects allocated in Rails, I actually understood most of this!!

Feedback for RailsConf organizers

During RailsConf, I jotted down notes on feedback for the conference organizers. They haven’t asked for it at all, but I thought I’d gather it here anyway :)

On the general experience for first time speakers:

• Overall, I felt really welcomed and supported as a first-time speaker, especially throughout the proposal process! I got really useful feedback during the CFP process.
• I wonder if it would be helpful to have the ability for people to self-identify as first-time speakers during the proposal process, so that these proposals in particular could get more feedback?
• The track conductor for the track my talk was on (Novices), Noel Rappin, actually came to my talk! That was much appreciated. He also reached out a couple weeks beforehand to see if he could help with anything, and followed through with getting some feedback for my slides. That was awesome. It would have been nice if he’d reached out a bit sooner, even, though I know people are busy.
• I regret not asking for a conference guide. There could maybe have been some of that kind of information included in the site upfront, like what to expect for meals/snacks.

Schedule:

• I’ve been thinking about the ideal slots for newbie talks to go into. Days-wise, it seems like not being on the first or last day is best. I think perhaps being the second talk in a block is also a bit better, as the previous talk can have “warmed up” the audience a bit.
• I’m curious whether it would help or hurt to promote first time speakers, like collecting that information somewhere as a sort of “hey! you should support these speakers and help make them feel welcome in the community!” Or would that instead be used by some people as a way to avoid certain talks, because they’re by inexperienced people?

Organized events:

• I enjoyed myself at the speaker dinner much more than I had expected! It helped a lot that I stuck around with Chuck and he’s so gregarious. I would’ve liked a bit more structure for introductions there though, like icebreakers of some kind, or games, or even assigned seating, like gathering up people on the same track together.
• I would LOVE to see more of this kind of non-alcohol socializing event (HT Chiu-Ki Chan)!! Next time I’m going to bring some games of my own to start or join in on a non-alcohol-based “birds of a feather” group event.

A/V:

• Definitely it would’ve helped to get the A/V details out sooner. I had already started on my slides by the time the official details came out (about 2 weeks before the conference) and just kept working on them, but then the weekend before, realized they were made with the wrong ratio and spent a few hours the day before my talk re-creating the slides for the right ratio instead.
• They provided clickers! That was really nice. Much more compact than the Wiimote I brought with me.
• The A/V staff were really friendly when I did my run through (“It’s my job to take care of how the slides look when projected, don’t worry about that”) so kudos there.

Misc:

• It would be great to include the Twitter handles for speakers with their bio listings.
• The seats in the rooms were pretty narrow and set up very close together. Maybe this is just a venue thing? But those of us that are more, er…generously sized, could use a bit more breathing space, and it could improve efficiency in the end with not having people sit every other seat as much.

Rules for my next conference talk

tl;dr Giving my first tech conference talk at RailsConf was awesome and overwhelming and surreal! Yet I felt insecure and disappointed after I gave my talk. I'm submitting it to more conferences--please let me know if you hear of any that could be a good fit! To do better next time, I will try to follow these rules:

Before the conference:

• Practice without reference to the speaker notes at all.
• Practice with random inserts of applause sounds close to the end (?)
• Ask to be scheduled early on in the conference.
• Ask to be put in a small room (Ben Orenstein's tip).
• Sign up for all offers of help, like A/V testing time, mentor/conference guide matchmaking.
• If I would prefer a change in the schedule, speak up as soon as the program is released so that there's some chance of getting that through before the physical programs are printed.
• Bring more outfit options or try it on beforehand at home for what I will feel confident and put together in (probably structured shirts over all soft knits).
• Decide on my goal for this talk, for how I will judge "success" this time. ([edited to add] Good reminder on this piece about giving yourself permission to suck at everything you're not currently working on to improve from my co-worker Bryan)

At the conference:

• DO NOT STAY LONG AT HAPPY HOURS AT BARS.
• Be back in my room by 9pm the night before my talk.
• Don't hesitate to tweet at other speakers when it seems like their talks are a good lead-in to mine.*

During the talk:

• Use the podium, however awkwardly placed, unless I'm absolutely confident in not needing to reference the speaker notes.
• Remember to take a picture from the stage!

After the talk:

• Once I'm calmed down a bit, if I get to talk to people who attended my talk, make sure to ask for specific feedback--especially on any new things** that I tried but am not entirely sure about for effectiveness.

I was so excited for and thrilled when my talk proposal for RailsConf was accepted! I poured hours and hours into preparing for it and practicing and successfully ignored my stress gagging in the half hour beforehand. I'd estimate it at about 85-90% of what my total all-out maximum effort for preparing would be, which isn't bad at all. But then when it actually came and went...I actually felt pretty shitty for a good 24 hours afterwards, despite all the social media-ing I did of positive responses to the talk.

It's taken me a few days to unpack those Feelings a bit. What I've settled on it is that public speaking is kind of like a performance art, like performing a piece at a music recital or competing in an athletic match. You put all this time and effort into preparing for the Big Day, and then sometimes, your actual performance just...falls a bit short of what you expected for yourself, what you know you are capable of accomplishing.***

There were things that were outside of my control. I randomly woke up at 6am on the day-of, after only 4 hours of sleep. There was another talk going on at the same time as mine that was also on the topic of onboarding for junior developers, which maybe thinned out my potential audience a bit and made me feel nervous that the room looked kind of empty when I started. The bright light on the elevated stage made it really hard to see out to whether people were reacting to what I was saying at all. The stage setup was a little strange, where the podium was on the far side from where the screen was, so that I, following the lead of previous presenters I'd seen in the same room, chose to move my laptop closer on a lower table, which made it harder to surreptitiously glance at my speaker notes.

(thanks Joanne**** for grabbing this photo!)

The one thing that really did a number on my confidence is that I didn't get any ripples of laughter from the audience on my funny slides--even the ones that pretty reliably got a chuckle from my practice audiences, like the owl one. This was maybe a combination of the room not being that full (and generally kind of cold, temperature-wise) and me just not having a full on grasp on comedic timing, which my co-worker and fellow RailsConf speaker Jason C told me is something that comes with more experience. This had also happened a few times in my practices, where the audience seemed incredibly stony-faced throughout the talk itself but then people came up afterwards and were very enthusiastic and encouraging. I probably just need to learn to take this less personally and not use it as a measure of how well a talk went.

Anyway, as a result of all the above, I tripped up a few times in what I was saying, and as such things go, each stumble made me feel more and more insecure.

I'm a little afraid of when the videos of the talks will come out. On the one hand, it may very well confirm the picture in my head of how the talk I went, but on the other, it probably is the only piece of data I would actually believe that the talk went better than I personally thought*****. Hearing from people who were there that they learned something from it helps a ton, but there's a bit of a silent evidence problem to relying on that (i.e. I don't hear from people who were lukewarm but polite enough not to go out of their way to tell me).

People have been very kind and supportive, which I am very grateful for. I still can't let go of a wish to sort of...get a 2nd chance, a do-over, at least on the video recording, so that it'd be free of um's and verbal trip-ups. So I am going forth and trying to find more conferences to submit this same talk to! Apparently that's a thing you can do? Which is great, because I want a better ROI out of all the time I put into it for sure. Please let me know if you hear of any CFPs that this talk could be a good fit for.

For good measure, here are some things I'm confident that I did well on:

• Started pretty early in preparing my talk, wrote up a rough draft within about a week of finding out it had been accepted.
• Worked out a very clear structure for the talk.
• Slides were clear, simple, but visually engaging with photos. Props to my co-worker Brent who gave me some great advice on adjusting the typography to be more beautiful.
• I'm particularly proud of the breadcrumb template design I came up with to help people keep track of where the talk was at.
• Getting a massage in the Exhibit Hall and then only doing my makeup right before the talk were both good calls. [edited to add] oh also I got my eyebrows done and colored streaks in my hair touched up the week before, which mostly just helped me feel more ready to face a camera.
• Getting some friends to sit in the front row helped with reducing the intimidation factor for sure, even if they'd all already seen the talk multiple times.
• I answered the questions that came in at the end much better than I thought I would! I was nervous about this, because you can't really practice this part, but it wasn't so bad.
• I slept in the next morning and skipped the keynote in favor on catching up on Twitter--I heard it was pretty funny, but Thursday was the best day by far of the conference of me, had a fabulous time, and that self-care was probably key to that.

Overall, I am very glad I did it! I will continue submitting and giving talks, and keep getting better at this. Sandi Metz is basically my role model here, her talk was so good, just really accessible and useful and well-done all around--once the videos from the conference are up, I'll put together a blog post of the talks I recommend watching.

To everyone that helped me, and everyone that attended: Thank you.

---

*Farrah Bostic's closing keynote on Tuesday, which talked a lot about her personal journey in learning to code a few years ago, was such a great lead-in to my talk! I should've reached out to her, but it felt like it would be a little too...sucking up, or nakedly ambitious, or something. Missed opportunity.

**Like the stretch break that's a bit awkwardly placed--maybe I need more charisma to pull it off? This talk had a 2/3-1/3 structure but I put the break at the halfway point instead. On the other hand, I definitely went to a good number of other talks where I personally could've used a stretch break in the middle so...this needs more testing and practice.

***This is probably the arena where my Tiger Mom and American influences on my childhood most coincide, by which I mean that it sort of feels like cheating to me, to say that you shouldn't care what other people think, but then only apply that when it's convenient. In other words, I may be my own harshest critic, but at the same time, I think my own standards are the ones I should live up to, given that I know from past performance that they aren't impossible to achieve for me, or particularly rare, which would be less than ~15% likelihood. I'm not sure I believe in going easy on yourself in general (well, as long as you aren't wallowing in beating yourself up to the point where you never pursue anything as a result), but I strive for kindness at least, and dusting myself up and continue to try anyway.

****Joanne and I were good friends back in middle school and then I went to a different high school and did not stay in touch with most people from that era. So we haven't seen each other in over 10 years! Running into and catching up with her at RailsConf was definitely a top highlight of the conference for me.

*****[edited to add] This seems like a super useful reference for when that video does come out: Instead of wincing: 10 things to look for on that video of your speech (thanks to Cate for bringing this post to Denise's attention)

If you're lucky enough to be recorded when you speak--whether you do the recording or someone else does--you've got a golden opportunity to learn things you might never otherwise know about how you speak.

Evolution of a talk proposal abstract

I'm speaking at RailsConf next month! Inspired by Julia Evans, I've made my talk proposal public. I also wanted to share a behind-the-scenes peek at what the process was like, since the feedback from the RailsConf organizers really helped me improve that abstract on top of the feedback I'd already gotten from friends and co-workers, as per their advice from that Write/Speak/Code Google Hangout last month.

Here's the abstract I originally submitted:

For developers that come from backgrounds other than a C.S. bachelor’s degree, frequently most of their focus is on acquiring technical knowledge. However, they very likely have many other skills, built up from when they weren’t studying computer science, that can help them in their roles immediately. This talk will discuss how to use non-technical skills such as relationship building and project management to ramp up more quickly and provide value to your team now.

The first piece of feedback I got was very encouraging on the appeal of the content and noted that I should try to get senior devs to come as well, since the organizer thought they'd be able to take something away from it too. In all fairness, Chuck had totally already given me this advice a couple weeks before when I was telling him about my idea, but I was worried about fitting enough details into the 500 characters allotted with what the organizers had said about not being afraid to "give away" more of the talk in the abstract. Here's v2:

For junior devs that don’t have C.S. degrees, frequently most of their focus is on acquiring technical knowledge. However, they bring with them many other skills, built up from when they weren’t studying C.S., that can help them in their roles immediately. This talk will discuss how junior devs can use non-technical skills such as relationship building and project management to provide value to their teams now, and how senior devs mentoring them can help them ramp up more quickly as a result.

I was feeling pretty good about this version. Then later on, I got more feedback from a different reviewer that again was very encouraging of the topic and proposed content but pointed out that phrasing was a bit awkward and run-on, particularly the first two sentences. She also encouraged me to think about ways to grab conference goers' attention to get them to come to my talk over the others that might be on at the same time. When I looked again at v2 again, I was a bit horrified that I'd used up all those characters across only 3 sentences! Hemingway would not approve. Here's the final version:

Are you from a non-C.S. background? What about someone you mentor? Many junior devs’ top focus is building technical knowledge. However, they already have other skills that can help them in their roles immediately! Some of these include helping their team focus on the right tasks and working well with stakeholders like PM and support. This talk will discuss the non-technical contributions junior devs can make now and how their senior dev mentors can help them ramp up more quickly as a result.

Much improved, yes? I'm glad the conference organizers pushed me on this, I think it's objectively much better than the original. Spending lots of time to say more with less, since 2014.

Advice from RailsConf organizers on talk proposals

Write/Speak/Code organized a Google Hangout today to hear a bit more from RailsConf organizers on what they're looking for for their different talk tracks and what makes a good talk proposal.

#1 takeaway: you probably need to move some of the information in the Details section into the abstract.
#2 takeaway: the process is more flexible than you probably think.

Here are some of the other tips they shared:

Good-to-know points about the process:

• They're trying really hard to have a feedback loop here to help you improve your talk proposal and have it be a conversation, not a black hole--so it's worth applying just for this! 
• However, don't take it personally if you don't get specific feedback, could also just be luck of draw of whoever's reading your proposal, that they're currently overwhelmed, etc.
• They will consider pairing multiple shorter talks together, so if you don't feel you have enough for 30-35 minutes of talking, note this in your pitch and they may match up short talks together. Interesting topics over length.
• They are open to making new tracks out of the submission pool that they get, so just because you have an idea that doesn't fit perfectly into a specific track, submit it anyway! (note: probably not if there's something that says they are specifically not looking for talks in that particular area, though). 
• The live coding track is basically like a mass pairing session.

Coming up with talk ideas:

• Write down things you come across while you're working that make you excited to tell a co-worker about and you couldn't find a blog post on, then review these periodically to remind yourself what those were and see if they can be grown into a talk.
• If these things are codebase specific, you can generalize the topic by researching how the wider Rails community addresses the same problem, i.e. "we do it this way, but what are other Rails ways of doing ____"
• For talk ideas that are of the "I don't know much about this yet and want to propose a talk to learn about it" type, you obviously need to do some research, but you only need to do enough research to convince yourself (and later, the organizers) that there's enough content there to fill a talk. What's the story you want to tell? What's the outline? What's the ending (and there should be an ending)?
• Research can be along the lines of looking at what are the big players and libraries in this space.
• Keep note of your sources so that you'll be able to cite them when drawing your conclusions, attendees will want to look at them too later.
• It's totally ok to change your conclusion for your talk between when you propose it and when you give it, then you can talk about why you changed your mind (plus it probably also means there was something timely that made you change your mind).
• Great blog post from one of the track conductors: Conference Prompts: Or How to Submit Proposals and Influence People

On "that should've been a blog post" vs. a talk:

• Sometimes people say this just because there was a lot of reading out of text in the talk, so if you're doing a presentation, make sure you brush up on your public speaking skills.
• This can also be about length and depth, blog posts tend to be shorter.
• However this can also just be whatever's convenient, what medium you yourself prefer. You'd probably just execute it differently based on the medium rather than the topic itself.
• If you do write blog posts, they can still be a source to inspire a talk--can point to these to help persuade organizers that you have thought about this topic and are capable of pulling ideas together in at least one format.
• You can even link to other people's blog posts as your talk idea inspiration.

On the abstract:

• The abstract is your pitch to conference attendees, you're doing marketing here!
• Don't worry so much about "giving away" the content of your talk in the abstract, more details will actually make more people want to come == conference organize will want you to do this talk more.
• A good way to think about your pitch is to explain to people what they'll be able to do after your talk that they couldn't before.
• Read your abstract out loud and make sure to get people to proofread it for you, don't make silly mistakes here.

In conclusion, the conference organizers are nice and want you to submit talks! Thank you Leah, Noel, Ben, and Sarah for sharing your insights and Rebecca for organizing.

she++ conference at Stanford

On Saturday, I attended the second annual she++ conference at Stanford, a conference on women in technology for Stanford/high school students and Bay Area technologists that is organized by Stanford students.

The conference was free for high school and college students and $20 for general admission, which I thought was well worth it. The day started with some opening remarks from the student directors of the she++ and an opening address from Mike Schroepfer, the CTO of Facebook. This was followed by an excellent panel of female tech entrepreneurs, including Sandy Jen of Meebo (acquired last year by Google) and Debbie Sterling of GoldieBlox. I've been reading a bit about start-ups recently and that whole world seems a bit like an impenetrable alien planet to me but impossible to avoid while out here in San Francisco; I've heard that NYC and Boston, both cities I'm more familiar with, have quite a tech start-up scene as well but it wasn't until I've been out here for awhile that I started to realize that Silicon Valley is really a thing.

After the panel, they screened the she++ documentary, which was about 15 minutes long:


It's very well-produced and a nice, quick summary of the whole gender imbalance in tech thing, so I think I will try to get my high school to do a screening of it after I give a talk at their alumni day in a couple weeks (my talk is shaping up to be a bit like trying to get the students the join the cult of getting in tech...).

After the screening, we transitioned to the workshop portion of the day. I had been given the opportunity to sign up for a workshop ahead of time as an early ticket holder, though I didn't realize that there would only be one workshop session and not a whole afternoon of rotating amongst multiple sessions. Fortunately, I got my top choice, the puzzles and brainteasers workshop co-led by Keith Schwarz, a CS professor at Stanford, and Sophia, a CS major.

The setup for the workshop was quite interesting, they talked through some general principles of puzzle-solving a little bit first (connect the game to a different game you know how to solve, force opponents' decisions, try out smaller examples, draw pictures) and then gave us packets of two-player games for us to pair up with other attendees on to talk through collaboratively on what a winning strategy would be. I had a lot of fun with this and the time flew by. When they gathered us up at the end and started to talk through the answers, I stepped aside when they got to talking about the ones my partner and I hadn't gotten to solving yet so that I could keep working on them later. Afterwards, I got to talking to Keith a bit about Hackbright and coming to CS only recently and he was super nice and supportive about it. He reminded me quite a bit of one of my favorite professors at Boston College, an intro physics instructor who was really engaging.

Lunch was intended to be a mentoring lunch but the table I had chosen (with Sandy Jen) was already full somehow by the time I got there, so I ended up at another table with a few engineers from Box, LinkedIn, and Square. What was really cool was that when I told them I was from Hackbright, they had already heard about it! We had some interesting discussion as well about the challenges of the Groupon business since the engineer from Square had done his own start-up in that same space.

The final two events of the day were a student panel of female CS majors from Stanford and a discussion/Q&A between Ruchi Sanghvi and Marc Andreessen. I had considered skipping the student panel because I thought it wouldn't be too relevant for me, given that I will never be a CS major at Stanford, unlike the high school students or other Stanford students in the audience, nor am I entrusted with changing a workplace to better attract female CS grads. But it's not like I really had anywhere better to go and I figured I might as well check it out since it was evidently a huge hit last year and I might learn something from the questions that industry people asked of the students. The student panelists were all extremely well-spoken and self-possessed, so mainly I was left feeling envious of them, though of course I wish them well regardless.

The Q&A with Marc Andreessen was pretty great, though. He repeated what many of the entrepreneurs at the career panel had discussed, which was essentially that you should not start a company unless it's something that you can't stop thinking about and can't make yourself do anything else. Kelley asked him for his opinion on alternative methods of breaking into the tech industry like Hackbright and he had a very thoughtful answer, which was that it's unclear how much college is necessary for it anyway since people can get started in CS many years before they even go to college, so the greater challenge is how to get people to that level of 10,000 hours of practice to reach expertise. Also, he said that nothing truly innovative can be built during the short timeframe of hackathons, so I felt a bit validated that perhaps the main benefit that hackathons can offer is bringing people together who might not meet otherwise.

Finally, the two conference co-chairs closed of the day with an adorable "wrapping up rap" to further contribute towards breaking stereotypes.

Key takeaways:

• Only start a company for an idea you can't stop thinking about. Startups all go through the same traumatic experiences of just being told no all the time, so it's an irrational act that people do because they can't help themselves. 
• Innovation is hard to recognize when it's happening (see this essay on "Why There Aren't More Googles" from Paul Graham that has the Howard Aiken quote "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats").
• Share ideas, don’t hoard them--if you’ve thought of it, someone else is probably already doing it.
• Practice rapid prototyping, get started with the cheapest materials available to you and then go out to get feedback on your idea (Debbie Sterling did extensive research with the young female children of her friends to see what they liked to play with).
• Sandy Jen's story getting inspired by her "stupid friends" that failed the same difficult theoretical tests that she did going out and succeeding at being entrepreneurs ("if they can do it, so can I").
• When pitching to VCs, you can draw confidence from being an expert in the product since you built it and therefore the pitch is just an opportunity to teach the VCs about it.
• Be the person that brings the tools, be the goose that lays the golden egg.
• Failure is a part of learning, you are not failure yourself because you’ve failed at something.
• Interviewing advice: always keep going, don’t ever give up even if you feel you can’t get from pseudocode to real code.

Feedback for the conference organizers:

• It seems that the conference is targeted at both industry people as well as high school and college students, which are fairly different audiences, plus additional groups like us Hackbright students. I think it would be vastly helpful to set expectations on which sessions are targeted at which audiences while still allowing for mixing of groups, just so people can decide whether they'll attend a session because they think they can benefit from it directly themselves or if they're attending as more of an observational exercise. In general, I'd like to see a clearer and more specific mission statement for the conference.
• For the student organizers that had prepared intros and such, they should practice their public speaking skills a bit more so that they don’t have to read off of a prepared text. It was obvious that they'd put a lot of time and energy into putting on this conference and it really was very well-done, which couldn't come about without enthusiasm behind it, but that gets a bit lost when you can tell that someone's reading off of a pre-written statement about how excited they are for whatever's coming up next.
• When doing intros, it would be more effective to keep the personal stories of why they decided to get involved in the conference fairly short to keep the focus more on whatever it is that they're introducing. It's interesting and touching to know where people are coming from, but be concise unless you've been specifically asked to talk about why you care about this issue, like the keynote speakers.