Saturday, April 15, 2017

Knowing the Answer is Not Always Better Than Knowing How to Find It

An incredibly important skill I’ve learned in the several Course 6 classes I’ve taken is that if you don’t know the code for something, your immediate reaction should be to just look it up. Until very recently, this rule generalized to almost all the work I was doing. Until very recently, when I was preparing for my first journal club presentation ever. In 20.109, since I usually either don’t have my computer out or don’t want to touch it with my gloves on, I use a slightly modified version of this rule: if I don’t know how to do something, my first reaction is to ask one of the instructors. 

 Of course, following this rule leads me to ask very many completely unnecessary questions: 

“Maxine, where’s [insert reagent name here]?”
“It’s in the ice bucket on your bench.”

“Rob, R is giving me an error when I try to load the data from the directory, why is it complaining?”
“You put in an extra slash. See, it works now.”

When it came to the journal club presentation, however, I ran into trouble before I even started. I made the rookie mistake of leaving MIT before trying to download the paper I was presenting, and Cell wouldn’t let me access it. As usual, I emailed Maxine for help. She had unfortunately already left MIT as well and couldn’t access her computer, but luckily for me, Leslie saved the day and emailed me the paper.

In the past, I’ve had a lot of trouble reading scientific papers. A lot of the time, they’re just too information-heavy for the amount of time or level of motivation I have to try to understand them. Since I was traveling with my family, I decided to read it on the flight. If my past self were to propose that idea to me now, I would probably say something along the lines of, “Oh yeah, that’s brilliant! Try to read the paper while you’re super uncomfortable, the plane’s making a ton of noise, and you're sitting next to your siblings who are constantly bothering you about this, that, and the other thing. That will make it so much easier to understand the technical writing, what could possibly go wrong?” Surprisingly, this didn’t actually end up turning into a disaster, for one major reason: the paper was really interesting and well-written. I couldn’t believe that I was actually reading through the results section and almost completely following what was going on. I made it through the entire paper on that flight.

Of course, I didn’t understand everything in the paper. The researchers used an experimental technique that I had never seen before, so, following the rule of Course 6, I tried to look it up. The problem with advanced techniques in biological research, however, is that there is a certain level of sophistication above which the only online explanations of the techniques are other scientific papers, which would not be any easier for me to understand. My solution was to go to Leslie’s office hours.

When I arrived, Leslie was in the hallway. “Hey Damon, are you here to do some lab work?” she asked. (I often do work in the teaching lab outside of class for a project I am working on with a few seniors).
“I’m actually here for office hours,” I replied.
“Oh, my office hours?”
She seemed genuinely excited that I had come, the same way I’ve noticed all the teaching faculty are when students come to their office hours. I’ve realized that what makes them stand out most from other instructors I’ve had is that they are not only incredibly committed to but also really enjoy helping us understand what we are doing. 

When it came to actually giving the presentation, though, it turned out to be much more difficult that I expected. I told myself many times while I was preparing that it would just be like giving another presentation like I did many times during iGEM. The two key differences for journal club, however were that I wasn’t presenting my own work, so I wasn’t as much of an expert on what I was presenting, and I was also being graded on it. When I gave the Jamboree talk for iGEM in October, I remember that the presentation I and my three co-presenters gave was awesome. I was extremely happy with the talk we gave. Since out postdoc advisor recorded it for us, I have it saved on my computer, so, looking for inspiration, I decided to re-watch it the day before I gave my journal club presentation. The talk was good, but as I watched myself presenting, I couldn’t help but notice all of the mistakes I had made. Re-watching the presentation actually ended up making me feel even less confident about the journal club presentation. I expect the experience will be similar to my debriefing with Noreen next week.

It was actually good that I watched it, though, because it motivated me to practice, a lot. And, of course, when I couldn’t figure out how to explain part of the paper in an understandable way, I just went to Maxine for help.


In Java, methods (functions) can be set to throw exceptions when they get unexpected inputs, which is basically the equivalent of saying, “I’m not going to deal with this problem. I’m going to defer it higher up the chain (to whichever method called it).” The method at the top of the chain, however, can’t throw exceptions because there ins’t a method higher up to deal with it. Instead, this method has to have what’s called a try/catch block, which is an instruction for exactly how to handle each type of exception the method might encounter. In 20.109, I definitely “throw exceptions” a lot, since the teaching faculty can handle these exceptions for me. To all the teaching faculty, thank you for being my try/catch block. I know I’ll get my turn to pay it forward eventually.

No comments:

Post a Comment