TMI: Research Talk Etiquette
Aug. 3rd, 2012 07:57 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
timBecause I'm having a few moments of emo and angst about the difficulty of understanding Rust code that's recently been rewritten, as well as the eventual fate of seemingly every major project I undertake, instead of writing a daily blog post today I'm going to talk about something different. (After all, my blog is on Dreamwidth, not LiveJournal, so emo and angst shouldn't be the order of the day.)
I went to a Mozilla intern's final research talk today. It was a good talk, covering some impressive work. Here are some hints for people attending research talks. Actually, they're more like requirements than hints.
1. If the speaker answers a question in a way that you think is naïve, consider that you may have misunderstood what they said. It is always possible that you are wrong, and that what you think was an assertion of fact was actually intended as a hypothetical, simplifying assumption that the speaker does not actually think is true. Under no circumstances should you burst out laughing. Laughter has the tendency to get the rest of the room laughing too, whether or not they actually understood the reason for the laughter. At any rate, laughing at a speaker is really not appropriate under any circumstances unless they have just told a funny joke.
Even if you are friends with the speaker and think that your laughter is appropriate given the terms of your relationship, not everybody else in the audience knows that. Your behavior sets an example: in this case, that it's okay to laugh at people. It has an effect. Try to make it a good one.
2. If you have something snarky to say about the contents of a talk, say it to your friend afterward. Write it down, if that helps. Don't say it out loud during the talk, even if you think no one else can hear you. Always assume you're sitting next to the lead developer on the project that the speaker is speaking about, and that they have excellent hearing.
Respecting people isn't hard, but when people do stuff like this, it fosters a disrespectful culture. It also creates an environment where people are afraid to speak up, make mistakes, and be wrong. Everyone should be able to experiment, take risks, and express bold opinions without fear of being made fun of for not knowing something. When somebody needs to boost themself up at another person's expense, I always assume that they're deathly insecure and afraid of having their own ignorance exposed. But there's no need to be afraid. Building software is difficult, and nobody is naturally good at it. We can all build an environment where no one is afraid to expose their weaknesses -- which is to say, where no one is afraid to learn and grow.
I went to a Mozilla intern's final research talk today. It was a good talk, covering some impressive work. Here are some hints for people attending research talks. Actually, they're more like requirements than hints.
1. If the speaker answers a question in a way that you think is naïve, consider that you may have misunderstood what they said. It is always possible that you are wrong, and that what you think was an assertion of fact was actually intended as a hypothetical, simplifying assumption that the speaker does not actually think is true. Under no circumstances should you burst out laughing. Laughter has the tendency to get the rest of the room laughing too, whether or not they actually understood the reason for the laughter. At any rate, laughing at a speaker is really not appropriate under any circumstances unless they have just told a funny joke.
Even if you are friends with the speaker and think that your laughter is appropriate given the terms of your relationship, not everybody else in the audience knows that. Your behavior sets an example: in this case, that it's okay to laugh at people. It has an effect. Try to make it a good one.
2. If you have something snarky to say about the contents of a talk, say it to your friend afterward. Write it down, if that helps. Don't say it out loud during the talk, even if you think no one else can hear you. Always assume you're sitting next to the lead developer on the project that the speaker is speaking about, and that they have excellent hearing.
Respecting people isn't hard, but when people do stuff like this, it fosters a disrespectful culture. It also creates an environment where people are afraid to speak up, make mistakes, and be wrong. Everyone should be able to experiment, take risks, and express bold opinions without fear of being made fun of for not knowing something. When somebody needs to boost themself up at another person's expense, I always assume that they're deathly insecure and afraid of having their own ignorance exposed. But there's no need to be afraid. Building software is difficult, and nobody is naturally good at it. We can all build an environment where no one is afraid to expose their weaknesses -- which is to say, where no one is afraid to learn and grow.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2012-08-04 03:36 am (UTC)*For a certain definition of "everybody" EG "cis male brocoders"
But there's no need to be afraid. Building software is difficult, and nobody is naturally good at it.
Oh, snap!
(no subject)
Date: 2012-08-04 07:20 am (UTC)(no subject)
Date: 2012-08-04 07:43 am (UTC)(no subject)
Date: 2012-08-04 04:01 am (UTC)(no subject)
Date: 2012-08-04 07:18 am (UTC)(no subject)
Date: 2012-08-09 07:54 am (UTC)(no subject)
Date: 2012-08-05 04:27 am (UTC)It's reasonable to make sure you understand the model (depending on the audience size), so asking what the model is fine. And at the end of the talk, it's a probably good to question whether the model is realistic or why it was chosen. But it's derailing and pointless to ask a "but aren't all your assumptions wrong" question in the middle of the talk.
I'm lately trying to stop it those sorts of questions, but I'm neither social skilled nor powerful, so I'm not that good at it.