Some thoughts on giving feedback effectively

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:

"Please give feedback that is Actionable, Specific, and Kind." @Bontgoy that's a great way of putting it.
— Adewale Oshineye (@ade_oshineye) October 22, 2014

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.

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.

My First Hackathon: HackEd 2.0

Last Tuesday, I participated in HackEd 2.0, an education-themed hackathon put on by the Gates Foundation and hosted by Facebook at their offices in Menlo Park, CA. As I was telling my husband about it the next day, I realized that I had quite a few Opinions on the experience, enough that I decided to dust off ye old blog and use it for when I have Many Things to Say, more than can fit into 140 character tweets.

Background:
The purpose of this hackathon was to build apps in these categories: college-going, social learning, and out-of-school study. We had to form up our teams ahead of time and submit an application with this as our app idea:

Our app will allow teachers to increase student engagement with assigned books through an enriching, multimedia learning experience. Students have many different learning styles and interests, so curriculums should be flexible and adaptable. For example, teaching a unit on the book The Kite Runner could incorporate the history of Afghanistan for history-lovers, discussions on artistic expression (and repression) for art-lovers, and videos on kite fighting for sports-lovers. Our app will enable teachers to easily collect and share such materials with students and perhaps other teachers as well, fostering discussion and sharing of best practices.

We found out that we had been accepted as one of the 25 teams to participate about two weeks before the hackathon took place. Two other Hackbright teams were also accepted.

This was the first hackathon for most of us and we were all pretty much total newbies to programming just five weeks earlier at the start of Hackbright, so none of us really knew what we were getting ourselves into. We attempted to prepare for it by meeting a couple times to flesh out the details of what we wanted our app to do a bit more and go through the materials that the Gates Foundation had provided.

Day of:
The organizers made us feel really welcome and kept us well fed throughout the day, with a breakfast spread that included bagels and lox, a taco bar for lunch, and sushi for dinner, along with easy access to a microkitchen with an excellent spread of snacks and drinks. The hackathon was held in a giant room that had many different couch sections for teams to use as their home bases, and there were plenty of outlets to keep our laptops charged.

Sheryl Sandberg gave the keynote/opening speech that emphasized the dire straits that the U.S. education system is currently in, which was followed by a representative from the Gates Foundation going through some of the statistics comparing the rate at which kids from middle-high income families get into and graduate from college vs. kids from low-income backgrounds. The last talk was by someone on Facebook's developer relations team that went over the basics of how to get user data out of Facebook and some tools you could use to learn about their API. After that, they set us loose to hack away for the next 5 hours before we would have to get up in front of the whole room to do a 3 minute pitch of our idea and demo our app.

I then proceeded to spend the next three hours (60% of our allotted time!) to figure out how to do the following:

This is about 10 lines of code total. I modified the example Python-Facebook app from Heroku so that it would also request permission to access the Facebook user's Interests and then display those interests once the user had logged in.

Why did it take that long to do something that turned out to be fairly simple? Getting even just the example app to run took me awhile and then it was a repeated cycle of reading through Facebook's documentation for developers and poking at the example app to see which code changes had any effect. Turns out, it takes awhile to make any headway on learning someone's API. It was very satisfying when I got those two interests from my profile to finally show up on the app page, though, and I passed over those bits of code to my teammates and spent the remaining two hours working on our pitch.

The hackathon had two pitch coaches roaming around that you could grab and try to get advice from. It was pretty informal; going in, I had thought that there would be structured sessions that would teach you how to pitch effectively at a hackathon. I'm actually not quite sure if they were Facebook or Gates Foundation employees, but the one I talked to basically said that our idea was too broad and content-driven (rather than technology-driven) and had been attempted by many others before without much success. Once he gave me some examples of how we could've tried to tackle a smaller problem instead, I could see what he meant, but this was advice that would've been more helpful two weeks before rather than two hours before the pitch was due. He did give me some practical advice in that last year, many people had apps that they wanted to demo but could've managed their time better to talk less and demo more in their precious three minutes.

I went back to my group and discussed this with them, but at that point we felt we didn't have enough time to make a major change in what we were doing (since we couldn't fully get what we wanted to do working anyway) so we soldiered on. I pulled together a few slides for the pitch and signed us up for a slot on the early side, figuring that the judges would probably get pretty bleary-eyed near the end of all the pitches.

Once it came time to do the pitches, they set it up so that while one group was presenting, another group could get connected and they tested it was working in the back somewhere, but it went slightly awry with ours for some reason. The woman keeping track of the timer was very kind and paused it while we sorted that out. It was good (and thankfully brief) practice in public speaking.

Most of the teams created an app in the college-going category, with a few more in the social learning category, and the fewest in the out-of-school study category, which is what we entered ours in. The winner in our group, Quizlet's Lockscreen, had a working mobile app that gets you to practice vocabulary in foreign languages before you can unlock your phone. Pretty cool and nifty, though on the other hand, this is what their company does for a living ("simple tools that allow you to study anything, for free").

Advice for new developers attending their first hackathon:

• SIMPLIFY THE SCOPE OF YOUR APP, especially for a one-day hackathon like this one. It's much better to feel like you have plenty of time to tack on stuff later rather than rushing desperately to get something, anything done.
• Reduce any pressure you put on yourself as much as possible. I started getting a bit nervous about the whole thing the night before but felt a lot better once I decided to think of the day as "a visit to Facebook that happened to have some hacking work thrown in."
• Focus on one small, new thing that you want to learn. For me, it was just how to pull out the user's profile data that we wanted, but I think some the other teams got a bit overwhelmed by all the different pieces it would take to get the app up and running on Heroku and such and left Facebook feeling really demoralized and defeated. :(
• If you have the time/inclination, try to go through any basic tutorials on that API with an example app beforehand. If you can't do it beforehand, try to make your app something that you can just adapt the example app into to use to reduce the things that you have to do, like figuring out how to build the login process.
• Befriend someone with frontend/design skills so that you have something pretty for your demo.
• Even though it's only a three minute pitch, it's still worthwhile to figure out what you want to say and show and practice it beforehand so you know how to pace yourself. There were a few teams that ran out of time to show all the other cool features they'd built, which was a shame.

Feedback for Facebook:

• I had a hard time wading through the developer documentation. A lot of that was of course my own inexperience, but it seemed like there were two levels of documentation--really high-level best practices (like these on asking for permissions generally when I was trying to figure out how you ask for specific permissions) and then really detailed documentation on the specific properties. It didn't seem like there was much in the middle to connect the dots for "ok, I know I want to ask for permission to access user_interests, but how do I do that?" 
• The Graph API explorer tool is awesome (once I figured out how to use it and that its purpose is to allow you to get a sense of the structure of the data you're requesting).
• A more detailed, optional session on using the Facebook API for newbie programmers would've been well worth the time for us to attend.

Feedback for the Gates Foundation:

• If there are people unfamiliar with the edtech industry attending the event, it would be helpful to include some summaries on other strategies and apps that have been tried and what the difficulties encountered were.
• Since the ideas are submitted ahead of time and therefore go through a preliminary judging for the application, someone with experience should give some quick feedback right then to help the team with planning.
• It may be worthwhile to reconsider the format of this hackathon so that it's more productive towards the Gates Foundation's goals "to do things differently, not just better." Extending it to two days could be a start, but I've been thinking that the innovation that springs from a hackathon-type event comes from strangers with very different areas of expertise working together to develop a new idea, which you don't have as much with pre-formed teams. To get more of that, you could have either a longer competition where the entrants have a few months and can start coding as soon as they know that their idea has been accepted, or a hackathon where ideas and teams are formed at the beginning of the first day.

1752 words of description and Opinions, not too shabby. For another take on the same event, my teammate Kelley wrote a HackEd 2.0 recap post as well.