On not having to explain why things are inappropriate

December 23, 2014

Over the past couple of years, I’ve noticed a bit of a trend amongst those who would consider themselves activists for one cause or another that’s essentially, “it’s not the underprivileged person’s job to educate people with people about their privilege.” Or, somewhat surprised responses to general questions from an ignorant person that they are ignorant on a topic the activist cares deeply about.

To be clear, for the record: I do not at all disagree that it would be best if people would put in more effort to examine their own privilege. People educating themselves is a much more scalable way to approach the problem when there are limited resources in time and energy. I’m very fortunate in that I haven't yet had so many experiences in having to explain the same thing over and over to others that I feel completely wearied by the effort and resentful of having that being seen as my “responsibility” to represent some entire group that I might be a part of.

The area where I might have come closest on this on is sharing with people who didn’t grow up around many Asian-American immigrant families what that was like. Amy Chua made this a lot easier in the last few years by writing her Tiger Mom book, but I just don’t particularly get tired of talking about how my childhood was different from a lot of other people’s with things like, “oh, you got a 99 on that math test? what did you do wrong?” kind of thing.

Here’s the big BUT that I’m of course leading up to: BUT, while it would be ideal for people to put more effort in, especially those that describe themselves as allies, I see the reality of the world as one where people are mainly motivated to do things that benefit themselves. Pretty much by definition, someone with privilege generally benefits from not examining that privilege too deeply. A layperson cares less about an issue than an activist does, because they’d be an activist already otherwise!

So appealing to people’s better natures and calling for them to do work seems to me as though it will be inevitably less successful.

If you’re the one that cares more about something, telling people more or less, “if you were a good person, you would care more, and if you cared more, you would do work and know more about it already” is not very effective to getting people to be on your side.

I watched a discussion awhile back about the challenges in interactions between socially awkward people* and people who don’t feel safe in a certain environment. On the one side, I don’t think it’s the “victim’s” responsibility to have to say right then and there, “you’re making me uncomfortable, please stop that.” There are plenty of good reasons why that is not a catch-all solution to resolving these situations.

My issue is with people for whom it seems almost a matter of principle that they should not have to explain to someone why something is inappropriate and should therefore be stopped. It’s almost like an assumption that people should just know what they should do to be decent human beings, by generally acceptable standards. Like again yes, ideally, we would never have to explain to any guys why street harassment is a bad thing they should not do.

But, when you run into something you want it to be stopped, your ultimate goal is to have fewer instances of this happening in the world, right? And explaining why it’s inappropriate will help you achieve that goal, in my opinion.

You may have another goal of not wanting to spend all your energy fighting with and educating other people all the time, which is also a perfectly fair and legitimate choice. But to me, it seems like having a principled stance against having to clearly explain the problem (which is not to say you have to have a customized response each time either, you can point people to something pre-written to read, if you have it) and always expressing your (valid, and deserved) anger at the world being an unfair place can get in the way of you getting what you want.

In conclusion, as a general life philosophy: Staying upset about how people are fundamentally pretty selfish and lazy can be a distraction from getting what you actually want. Do the things that will get you what you want instead.

Further reading: Getting More: How to Negotiate to Achieve Your Goals in the Real World

*One example is men in tech who’ve been diagnosed with autism-spectrum syndromes like Aspergers, or are just generally kind of awkward, interacting with women in tech, who are in the minority, and in general who in all likelihood have had to deal with many, many male creeps in her past. Yes, "autism is to blame for harassment of women" is trotted out and used as an excuse, even though pretty much everyone is capable of learning sufficient social norms not to harass others. However, there are a non-zero number of real-life cases where social awkwardness is in fact the cause.

Some thoughts on giving feedback effectively

December 16, 2014

I think a lot about the process of giving and receiving feedback a lot, because one of the concepts I'm a little obsessed with is how what you don't know, that you don't know, can have an outsized impact (the black swan theory). But also, I got a lot of feedback myself earlier in my career that I needed to improve at delivering feedback in the right forums and to the right people in a way that would actually effect the change I wanted to see.

I don't tend to have very much trouble coming up with content for feedback thanks to being trained by my Tiger Mom to always, always, relentlessly be asking and thinking about, “How could this be better? How could this be more efficient?” That incessant drive to improve is enormously powerful, but I know it can also be enormously irritating to be around, too. I've learned that appropriately managing one's more annoying tendencies can be really useful to actually getting what you want. Another result of that drive is that I often have Many Opinions and Ideas, but there can be so many of them that I don't necessarily even care all that much about a lot of them! So I've developed some tactics for achieving the long-term changes I do care most about.

I'll use the example of giving people feedback on conference talks they're practicing, since that's been something I've been doing a lot of this in the past year. One co-worker told me after one such a practice talk that he's automatically going to invite me to all his future practice talks to get my feedback, which made me feel like I might be doing something right nowadays!

There's a lot that's been written about the “compliment sandwich.” The basic idea is that because people tend to react more strongly to criticism, you should deliver positive feedback and encouragement before and after a piece of negative feedback in order to soften it. However, in practice, this can come across as kind of fake and formulaic, resulting in people still only hearing the negative feedback and then thinking you're a phony on top of it, like in this 30 Rock bit.

I think the key nugget to this idea is that you need to avoid overwhelming people with criticism. If you don't have enough substantive positive feedback of specific things people did well and should do more of, you need to prioritize and limit the pieces of negative feedback you give them, at least in that same session. You can always save the less important feedback for the next time. If I go to multiple practices of the same talk, usually at the very least, I can comment on the ways in which I observed they're put a lot of work into improving from the last practice.

When I'm sitting in on a practice talk, I take copious notes on items that probably fall into one of these categories:
  • the points that I strongly agree with, usually with some additional suggested examples for them to use to further emphasize that point
  • any slides or points I thought were particularly clever or awesome in some way
  • the parts I was confused by and any questions that came up in my mind (a preview of what might come up in Q&A)
  • my observations on any differences between the emergent structure from their talk based on my synthesis of the content as they've delivered it, and the actual structure of their talk, in order to make the talk flow more smoothly (ex. “I think part 2 was actually good background for part 1, so you should reverse the order of those two sections”)
  • any sections that could be candidates for being cut, if they're going over time
  • which sections I think they should definitely keep

The last two are particular items to watch out for, because I've noticed that in a lot of these practice talks, the presenters are usually running pretty close to time already, and then everyone (including myself) usually gives them suggestions of even more stuff they can include, which would of course bring them over time. So input on prioritizing what should be kept and what should be cut can be very useful and reduce being overwhelmed by the volume of suggested changes.

Once I have these notes down, because I tend to have a lot of them, I'll usually try to give it a moment and let other people start off with giving their feedback, while I take some time to prioritize and organize my points. Usually other people are less verbose, so it helps warm up the mood for feedback before I go in all guns blazing. The prioritization is to make sure I have enough of the positive stuff upfront and I can lead off with the suggestions I think would have the biggest impact. I also try to save a piece of really easily changed item for the end, so that if nothing else, people can seize on that small thing to change and feel good about accomplishing that (and helps me save face if they hate all my other suggestions). This prioritizing on the fly takes some practice. My notes have a lot of circles and arrows drawn on them after I do this.

Finally, another important tactic is to modulate your feedback based on how it's being received. Some people aren't very good yet at receiving feedback without feeling defensive. You can tell this is happening when you start getting a lot of explanations for why they chose to do things in that talk, versus just writing down or asking questions back to clarify the feedback. Again, because of that Tiger Mom influence, my instinct tends to be to still want to help people even if they don't really want to be helped that much right now. However, I've learned that preserving the relationship is more effective overall (and gives you a chance for your feedback to be established as trustworthy, even if it isn't taken at first), so I'll persist a little bit but then rapidly cut out a lot of what I was going to say if it seems like it isn't going over all that well.

In conclusion, this:

Some quick thoughts on talk proposals

December 9, 2014

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.

Guide for newbie tech conference attendees

December 2, 2014

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)

Belgium is pretty great

November 25, 2014

One of the reasons I was particularly looking forward to going to ArrrrCamp is that it's held in Belgium and I'd never been there before. I was able to squeeze in a bit of sightseeing and had a really fun time! I would definitely go back again some time.

The conference is held in Ghent. I flew in to Brussels and took the train up to Ghent, which was a ~50 minute ride. The trains run about twice an hour. There are ticket vending machines around, where the main screen interface is in English but then the instructions to the side where you swipe your credit card weren't, so I never managed to make them work for me. Not sure if my card was getting declined (I'd put a travel notice on my card beforehand, and it seemed to work everywhere else, even if it was a bit slow to get the approval sometimes) or it wanted some input from me that I didn't know to give. There are ticket windows with actual people, so I ended up getting my tickets from them. Pretty much everyone spoke fluent English and I never felt condescended to for only speaking English too, so that was really nice.

It would have been helpful to have some euros in cash on me, particularly coins. I purposely withdrew a bit more than I expected to need for this trip, so I'd have a few bills and coins for the next time I'm in the EU and be able to get by until I can find an ATM.

I basically followed the city's guide for if you have a half-day in Ghent. Ghent is really cool, it's got plenty of old structures (and art museums that I'd hit next time), but it's quite developed as a city and is obviously still a place where normal people live and work. I really liked that about it. I walked by a high school just was it was letting out and there were so many stylish students, from the Belgian equivalent of the punk/goth kids to the hipsters to girls wearing hijab.

Church with the panels: 4 euros, I got here just 20 minutes before closing, so wasn't able to listen to too much of the audio guide, but what I did hear seemed like an accessible and thorough explanation of the different panels. The church didn't look like much from the outside with a lot of restoration work going on, but it was worth it even just to walk inside and see the immensity of it, with the great height and the stained glass windows. There were signs saying not to take photos, so I refrained.

Belfry: 6 euros. This was fun. You get a laminated self-guided tour with your ticket, and there's a lift from the second floor up to the top level you can get to, so there's not too much of climbing narrow stairs. Great views of the whole city from the top level, where you can walk around outside a bit, though it's quite narrow and I'm glad there wasn't anyone else there since I went so close to closing time. Mostly fairly narrow openings to the outside, so it might be ok even if you have a fear of heights.

Each of the different floors had a bit of mini-exhibit. I accidentally timed it well to be at the top during the 5:30 bells, and could see the mechanism running that. There were also an exhibit of the retired versions of their famous dragon weathervane. That dragon is actually kind of adorable! What I might've enjoyed the most was this short documentary playing on a loop about how the bells are cast that had English subtitles. Lots of fun kids toys in their gift shop, like wooden swords, slingshots, and other dragon-themed items.

From there, I walked over to see the castle. My guidebook said there isn't much inside, and it had closed at 6, so I just walked around the outside. It's not too big but it's still just funny to me that there's this medieval castle in the middle of cars and tram lines. I found a nice view around the back that basically looks to me like the castle in Robin Hood.

Speaking of the cars and tram lines, you should be careful when walking around just because the sidewalks are pretty narrow and there isn't really the concept of a shoulder to the road as a buffer zone between pedestrians on the sidewalk and the cars/trams. Also, in some places, there seems to be a maroon-painted half of the sidewalk that's for cyclists, so stay out of that if you can.

There are some really beautiful views around the canals and bridges, at dusk and at night, so make sure to check those out.

I didn't go out for specific nice meals out while I was in Ghent, but had some very high quality pasta and great service at the bistro next to the venue. The waiter very patiently read and translated every single line of their menu for me, though I saw plenty of places with English menus outside too—probably more designed for tourists?

Oh the breakfast at the hotel deserves its own paragraph: this was maybe the best hotel breakfast buffet I've ever had, and I've traveled a fair amount. First, they had really good chocolate croissants, the sausage/scrambled eggs/bacon were quite decent, and the fruit juice machine included grapefruit juice. More importantly, though, they had a make-your-own-boiled egg machine!!!

Just a bowl of raw eggs and this machine of boiling water with little mesh holders for individual eggs, and a timer so you could have soft- or hard-boiled eggs. And, actually egg cups! I mangled it pretty badly the first time I made some soft-boiled eggs, but one of the days, I ran into some other people from the conference who kindly taught me how to successfully eat boiled eggs on an egg cup.

My last comment about Ghent is to be careful about which train you get on for trying to get back to the airport—I should've asked the ticket agent about this, but I just got on a train with another ArrrrCamp attendee that was also heading into Brussels. He wasn't going to the airport though, and I realized that the train I was on didn't actually go to the airport station, which is Brussel-Nationaal-Luchthaven. I had to take a 65 euro taxi to have a shot of getting there in time and then begged for leniency from the counter agent to let me check my bag with less than an hour to go before the flight.

I planned my trip so I basically had all day Saturday free. Because I was staying an extra night in the same hotel in Ghent, I decided not to spend the day in Brussels and instead took the 25 minute train ride up to Bruges. Yes, mostly because I'd seen the movie In Bruges years ago and wanted to be able to say I'd been in Bruges.

I was prepared for it to be pretty touristy, but really, it was tourists everywhere!! Really almost felt more like an amusement park of medieval architecture, with many many many large groups of people walking around together. Seems it's very popular with middle-aged and retired tourists, as well as British folks visiting for the weekend. Luckily, it still felt mostly peaceful while walking around, I just had to work quickly to try to get photos without enormous numbers of people in them. There is a reason tourists flock there—it really is very beautiful and well-preserved.

I got in around 10 and first went to buy a ticket to later take a tour at the brewery. Then I walked over to the Church of Our Lady to see the Michelangelo statue (2 euros). Unfortunately you can't get too close to it, but you can still make out the artistry. I also popped into the convent place.

The brewery tour was really fun. It was more different stories about the company's history than about the process of brewing beer, but our guide was quite funny and the view from the top was so good I decided I didn't need to rush to try to climb the belfry for the view from there. When they say that there are lot of really steep and narrow steps to climb as part of this tour though, they aren't kidding. The drink they give you at the end as part of your ticket was a legitimate amount, and even though I'm not particularly into beer, I really liked it.

I then did the walk in Rick Steves' book, but backwards, and met up with the bike tour I'd booked with Quasimundo for the afternoon. There were only four of us, and the guide ended up taking us out on his far route, which was 40km total. My butt was pretty sore at the end of it, the bike I got didn't fit me all that well, but they did have helmets available if you wanted one, despite all the Belgians I'd seen biking around with no helmets.

It was really refreshing to break away from the crowds and get into the countryside. We stopped just a few times for history talk + I snapped a few photos, so it was mostly chatting with the other tourists in the group and admiring the tree-lined canals and fields and sky. Also, cows. Some very healthy-looking cows out there. We did stop at a small pub and had another drink there.

When I got back, I rushed back to the brewery to pick up some souvenirs for my dad and father-in-law, and then to a chocolate shop to bring back for my co-workers, mom/sister, and myself of course. I stopped in Dumon, which was recommended in Rick Steves' book. Tiny shop really, and they told me they're just one of only 5 families left in Bruges making chocolate still. I would've liked to get some lace-themed souvenirs from one of the many other shops, but there was a sudden downpour and I didn't make it to any of them in time before they closed. I was told most of those are just made in China now anyway because handmade lace is incredibly expensive, but it still would've been nice to get a little lace Christmas ornament for my mother-in-law. Oh well, maybe next time.

The last thing I did in Bruges was get mussels, which came with fries and a trio of mayo dipping sauces. I would've liked to go to the green stands in Market Square, but I probably wouldn't make a special effort to get to Bruges again. It might be a fun short romantic weekend away, but my goal was say that I'd been IN BRUGES and I accomplished that.

I bought a used copy of an older version of Rick Steves' abridged book traveling to Brussels and Bruges. This was really nice, the book was nice and light while still being informative. I wish I'd looked more closely when I got the book from Powell's, I thought I was buying the more recent version of this some guidebook which includes Ghent. If you're doing a Brussels/Ghent/Bruges trip, that's the one I'd recommend.

I also checked out the Lonely Planet guide to Belgium from the library. This was useful since my other book didn't include Ghent, so I was able to use that to get around. It's a bit heavy to lug around though, when I didn't need all the rest of the content and didn't need information about hotels and such too. Might be more useful if you're planning a longer trip from scratch and are going to farther apart places.

Adapting a previously-given talk

November 18, 2014

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

November 11, 2014

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:
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.

ArrrrCamp 2014

November 4, 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.

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!!

Be a Better Developer (no code required)

November 2, 2014

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.

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.

Chicago writeup

May 27, 2014

I had a fabulous time in Chicago for RailsConf! Here are my recommendations for if you just have a couple days in the city:


Portillo's: omg amazing Italian beef sandwich, which I got with both hot and sweet peppers. Juicy, like beef should be, soft bread to soak up all those juices...I wish I'd gotten another one.

I did also get a Chicago-style hot dog on another visit but I didn't feel that melded as well together. They're also known for their chocolate cake, which has mayo in it, of all things. It was indeed very rich, to the point where I only had a couple bites of the giant slice.

Ricobene’s breaded steak sandwich: when I found out I'd be going to Chicago, this sandwich review was the first thing that came to mind.

It's in Chinatown and not particularly direct to get to on public transit, but the walk there from the Cermak-Chinatown was fine. There's not much around, but it was pretty packed inside, with families, teenagers, cops...everyone knows what's up:

So yeah, this sandwich is indeed pretty amazing (as was their chicken parm). You should go. But only, you know, if you like meat and carbs at all.


My cousin had recommended the Chicago Architecture Foundation River Cruise, which was really fun and educational! I waited to make sure the weather would be nice before buying tickets at the riverside kiosk about an hour before the first cruise on Saturday.

The tour guide was really knowledgeable and unlike some reviews I had read online, I thought the information was really accessible and interesting. I would not have noticed all the interesting details and thought behind the city's architecture at all otherwise. It does get pretty windy and cold out on the water even when it's sunny out, so bundle up unless it's deep into the summer.

Millennium Park, of course, with The Bean:

The Art Institute of Chicago is right there too, which was a good-sized museum, not overwhelmingly large. Famous stuff they've got: American GothicA Sunday Afternoon on the Island of La Grande Jatte, and usually they've got Nighthawks too though it wasn't there when I visited sadly. Also, these gorgeous stained glass windows by Chagall:

Took in a show at the Second City, which is probably a requirement:

Went to this Trapped in a Room with a Zombie with a friend at her suggestion, that was a fabulous time if you like solving puzzles under pressure (I'm an engineer, of course I'm all over that!) With a group of up to 11 other people, you're locked in a room with a (actor playing a) zombie chained to the wall and various puzzles/clues scattered around for how to find the key to get out of the room. Its chain extend by another foot every 5 minutes, and if the zombie touches you, you're dead, so you've got an hour to get out. The success rate is apparently only around 28%, and yet our group managed to succeed!

And lastly, instead of the Skywalk, my friend recommend going up for a drink in the Hancock Tower Lounge for an equally excellent view of the city and approximately the same cost (including the drinks!). There was a bit of a line to get in there, which might've been better if we'd gotten there a bit earlier before all the people wearing tight dresses and shiny suits came out.

Next time I'm in Chicago, I will definitely go back for those beef sandwiches again, set aside more time to wander through the Art Institute, and try to find some of the public art sculptures.

Feedback for RailsConf organizers

May 20, 2014

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.

  • 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.

  • 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.

  • 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

April 30, 2014

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:
  • 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.

How to Be a Better Junior Developer

April 25, 2014

This post was originally published in the New Relic blog on 4/23/14. It is the blog post version of my talk for RailsConf 2014 in Chicago, the slides for which are embedded at the end of this post.

Over the last couple of years, New Relic has hired multiple graduates of various coding bootcamps and “non-traditional” backgrounds, including me! After I earned my Bachelor’s degree, I was actually all set to attend medical school, when I got a job at Google in technical support. Some four years later, I took a sabbatical to attend Hackbright Academy, a 10-week (now 12-week) program teaching women how to code. Before the end of the very first week, I knew I had finally found a career direction I actually wanted to actively pursue.

One of my biggest worries, though, was that I would be throwing away my past experience and the skills I had developed in a different domain, to start over entirely in a new field — one where I’d be up against developers who had decades more experience. Fortunately, as I settled into the role, with the help of the many great mentors I got to work with, I came to the following realizations:
  • Being a developer is really about constantly learning.
  • There is a lot to engineering that actually isn’t directly coding.

It became clear that there are many ways to leverage the skills I’d developed in other domains, even as a junior developer with so much to learn. Having gone through that period of uncertainty myself, I wanted to spread the following two messages:
  • Junior devs: There are ways you can contribute to your team while you’re still learning the ropes.
  • Mentors: Tailoring your guidance to junior developer needs will help them feel more confident and productive.

So much to learn

When it comes to the challenge of having so much to learn as a junior developer, the most important thing is not to try to do it all on your own. Here are three approaches you can take:

1. Get people to want to help you
Through building relationships on your own team and across other teams, you expand the network of people you can ask for help when you get stuck. To get the most out of that network, it’s crucial to show that you value other people’s time and get as far as you can on your own. For one, you’ll learn a lot faster if you try it yourself first (Google and StackOverflow are your friends). This also makes your experienced co-workers feel more helpful and confident you’ll put their advice to good use the next time you run into a similar problem.

2. Make it easy for people to help you
It can be really hard to articulate what it is you’re confused about, when you may not even have the vocabulary to describe the topic. Here’s a template that I like to use when asking for help:
“I am trying to ___, so that I can ___.
I’m running into ___.
I’ve looked at ___ and tried ___.”
For example, here’s how I filled this out recently: “I am trying to understand why this banner shows up on this account, so that I can tell the client whether they need to listen to that warning. I’m running into a problem with finding this record. I’ve looked at the model and tried reproducing the issue locally.”

3. Narrow the scope of what you have to learn
Much like tackling a gnarly technical problem, you should also try to limit your scope so it’s not so overwhelming. There are an infinite number of topics you can pursue, but mentors can help prioritize them. (My personal goal: to actually build a Rails app of my own.)

Helping your team

As a junior dev, it’s natural to be asking yourself: how can I contribute to my team when I still need so much help? Something to remember is that in a world where there aren’t enough developers* for all the developer jobs out there, it’s not necessarily a choice between slow (junior) and fast (senior)…it’s a choice between having something built, and not having it at all. Here are some other tactics to keep in mind that will help you give back, above and beyond the code you write:

1. Ask good questions
I like to think of questions as a junior developer’s superpower. Asking good questions, like “are we working on the right thing?”, helps reveal any misunderstandings and assumptions. These would result in many wasted hours if they aren’t uncovered until later in the development cycle, so ask questions early on.

2. Give good feedback
Giving useful feedback to the right person, in the right venue, at the right time, is hard for a lot of people. But all industries have some kind of feedback mechanism, so this is likely something that even junior developers will get a good amount of practice with. You can also help anticipate possible confusion that may come from Sales or Support teams regarding any new releases or product updates.

3. Make your team look good to other teams
Just by being extra responsive, thorough, and empathetic to the other teams that you work with can go a long way. One particularly good opportunity to make your team look good to others is any demos of new features built by your team. You have a chance to demonstrate that your team has been thoughtful about the impact to other teams, like serviceability. I almost always write a script and do a practice run-through beforehand, so that I can ensure a more efficient and less error-prone demo.

How mentors can help junior developers

The above tips are aimed specifically at junior devs, but there are also a lot of things mentors can do to help junior developers feel valued and capable of making concrete contributions. I’m a big fan of having a lot of conversations upfront about things like how a junior dev’s learning style can be matched up with a senior dev’s teaching style. These discussions help make sure everyone’s time is used more efficiently. For example, you might discuss how often a junior dev likes to receive feedback and instructions, and how and when the senior dev prefers to be interrupted if any questions come up.

Also, if as a mentor you want to intentionally let a junior developer struggle a bit in order to learn something, let that person know that this is what you’re doing. This helps dispel feelings of imposter syndrome, where people lose confidence because they have the mistaken belief that this should feel easier, even though it is actually expected to feel difficult.


A junior dev doesn’t show up to their first engineering job as a blank slate. There are many opportunities to hack a junior developer’s existing skillset to help them ramp up faster and feel they’re providing value from day one. I’ll be giving a more in-depth talk today at RailsConf on this same topic, and we’ll update this post to with the recording and slide deck when it eventually goes up.

*We’re hiring!

Response to my talk at RailsConf, on Storify.

Additional recommended resources: