[Guest Post] How to Revise a Paper in 5 Easy Steps by Afeefah K. '21

This is a post by my good friend Claire, she’s an insanely amazing human being who has dreamt of being an admissions blogger since August 2016. Today Claire has achieved her dream and is goin to share this accomplishment with everyone she knows, her mom in particular. Check out her paper-writing, published-researcher becoming saga below:

———–

As a general disclaimer, I don’t think paper revisions should be like this. In fact, it should probably not be like this. But when you combine a major revision deadline of 4 weeks and an MIT undergrad in the midst of classes, clubs, internships, and a generally messy existence, then things go haywire and unpredictable, as things usually tend to do here. Here’s the unfolding of my research, from an organized beginning to a furious blur at the end.

Step 1: Avoid rejection!

It had been around two months since my supervisor and I submitted my manuscript [1]  related to our project on protein structure prediction when I got an email. I remember sitting at my desk in the Google Cambridge office in the late afternoon – almost everyone except my host and me had left the office, so I was sitting back in my chair, scrolling through my email when I saw the subject line “Decision made for ….’ flash in my notifications.

“Nope,” I thought to myself as I flicked it away – I had been rejected for a number of opportunities earlier that week, so I wasn’t in the mood for another set of bad news. “No rejection today,” I thought. “We reject rejection.”

1 hour later, I got two more emails from my supervisor’s OneDrive account with the manuscript document she submitted, along with a forwarded email with some comments.

“Not a rejection!” quickly became my life motto as we hit step 2 – addressing the peer reviewers.

Step 2 – Address the reviewers: approach with time management in mind.

Journals (or at least this one) always want you to resubmit within four weeks after addressing peer reviewer[2] comments, so things really moved quickly. Within two days, I found myself in a conference room at the office on the phone with my supervisor, staring at the 20 points that the reviewers brought up on my screen. Some were easy typos to resolve, but some of them were more involved – one comment in particular called one of my figures “an overload of information that makes my brain hurt when trying to interpret them.” My supervisor chuckled when she read that, and I nodded in agreement.

Unfortunately, this round of revisions also hit during a very inconvenient time in my life – I was right in the last week of my internship, which was me scrambling to finish my summer project and making slides it at midnight, right after which, I had planned for two weeks to visit family in Asia, where I’d have limited Internet connectivity. The fourth week of the revision period would coincide with the first week of classes, which is always filled with thousands of meetings, hours of unpacking, and general chaos.

The first week of this four week period I had spent finishing up internship stuff and packing and moving from summer housing in Random to fall housing in McCormick (a sweat-driven Tuesday morning haul), so my grind didn’t start until week 2, where I started off with a 14 hour sprint on an international flight to finish as much as I could without Internet.

I wouldn’t have been surprised if after the tenth hour, where everyone was passed out and the lights were out, that the flight attendants were concerned about me. Regardless, by the end of it when the lights came back on, I must’ve looked like one of those people who wander out of the stud at 6am after pulling an all nighter during finals week. [have been there, have done that]

I finished up the first draft of revisions by the end of Week 2 in Taiwan, powered by my parents’ mobile hotspot while seeking solace from the summer heat. By the time my supervisor got back to me, it was nearing the middle of Week 3, and I was on my way to Japan to relax for a few days before returning to campus. I briefly looked at the changes and made a few notes to myself before shutting my laptop and boarding the flight.

Step 3: Remain calm when things go wrong.

This is where tragedy strikes. The part in the story where everything suddenly unfolds and the main character finds themselves in an unpredictable predicament. The incoming tsunami over the horizon. The point where the reader feels that pit of dread drop in their stomach as things get worse and worse and worse, but also that comforting cloud of relief as they emerge back into reality thinking, “Wow, thank GOD that’s not me.”

I was on my way back to the States near the end of week 3 after a few days in Japan, feeling refreshed and ready for the semester. The night before my flight, I flipped open my laptop to work for an hour or so. I watched the power button flicker on and off. Funny, I thought, as I tried it again.

My fan ran intensely for five seconds before the light flickered off again. I started to panic. I tried turning my laptop on another ten times, each resulting in the power button lighting up for a few seconds and dimming again. I ran to the outlet, thinking maybe my laptop had drained its power while on sleep the past few days, but nothing helped.

I sat and stared at the wall. My mom asked quietly if I was ok. I nodded slowly, in a silent, but furious panic. All my data, figures, and code were stuck on my laptop that refused to turn on, and I had a week left to make the revisions happen. My Google search did nothing to dissuade my increasing heart rate as phrases like “fried motherboard” and “major hardware problem” flashed on my phone screen. A bead of sweat dripped down the side of my face as I formulated a desperate plan.

Step 4: Send some emails. Make some calls. Hack some computers (not really).

The day I arrived back in the US, I sent an email to IS&T requesting an emergency loaner laptop, which I wouldn’t receive until three days later because of Labor Day weekend. I prayed that Crashplan was magically backing up my computer even though I hadn’t opened it or updated it in nearly two years. I read online that it was now called Code42, which a) I hadn’t even known was a thing, b) might not necessarily be compatible with older versions of Crashplan, and c) might not even have been accessible because I didn’t remember making an account. My stress level increased, ever so slightly. My existence depended on my code still being retrievable from my very, very dead laptop.

After sending the email, I searched on Yelp for emergency PC services to revive my old laptop. A few places in Boston popped up, but none had stellar reviews – the one that had five stars on Yelp was all the way out in Brookline. (Out further than Fenway?? UNIMAGINABLE)

How desperate was I? Desperate enough to call the owner and ask for a Saturday appointment, and then trek out on the Green Line far enough that I started seeing more trees than buildings. I dropped off my laptop and explained what was wrong with it, trying to convey my college student level panic in my voice. The owner quickly took the computer in, wrote a few notes on a post-it, and sent me off.[3]

Adding to the running around, in order to retrieve the simulation trajectories that we had to rerun for a few additional experiments, I had to go into my group’s lab on Labor Day and find the workstation that had the simulation trajectory files. The workstation IP address had changed since the last time I had accessed it, so I couldn’t ssh[4] into it. Walking into the lab, I desperately hoped that the workstation was still where it was when I had last physically worked in the lab (more than nine months ago). It luckily was – I quickly typed in the username and password and hit “Log in”.

“Password incorrect”, the screen read. I tried again and got the same screen. I cursed silently and looked around, hoping no one was there to witness me guessing random permutations of the old password. Finally on my sixteenth guess, the screen unlocked. The new UROP’s directory from the summer was still open on the workstation, so I minimized the window and opened my own folder. The files were still where I expected them to be, and I uploaded everything to Dropbox so I could access them on my loaner laptop. I exhaled, relieved I was able to guess my way into the system. After writing down the new login info, I left, shooting my supervisor a quick email:

At exactly 9am the first day of Week 4, I dashed into IS&T and claimed my loaner laptop, a Dell, much like the one that crashed on me. I spent hours redownloading software, all my simulations from Dropbox, and most of my code from the cloud. (thank GOD for Crashplan. I owe my life to them). My supervisor had just emailed me asking to meet over Skype so we could coordinate a final document of revisions for approval from the PI, which gave me around 48 hours to accumulate all the new figures and revisions. But after coming this far, I was delirious with blind confidence that I would be able to finish everything by her deadline, which was 4pm Thursday of the first week of classes, right before her flight.

Sitting in the EECS lounge, making sure everything was perfect, I made it by the skin of my teeth and sent my supervisor the final changes at 3:53pm.

“Right on time!” she replied.

Step 5: Hope for the best!

 After our PI approved the changes, we sent back the final manuscript to the journal and hoped for the best. My senior year started, and I got back into the groove of classes and began working in my new group at CSAIL for my SuperUROP. I had in the back of my mind, a reminder to make the poster for my upcoming conference poster presentation related to the project, but I was mostly done, for now.

A few lessons from this story: sometimes shit hits the fan. Sometimes shit really hits the fan and it’s kind of unavoidable, but you have to learn to stay calm and adjust. Lots of things at MIT work out like this – people figure out majors aren’t right for them a year in; you have four exams in four days and crawl into S^3 on three hours of sleep; maybe you get pneumonia and have to drop some classes. But the thing about this place is that we’re always learning to be flexible and to keep moving forward (in whichever direction that may be), no matter what the circumstances.

Also back up your computer. That’s also a really big lesson.

Lastly, after all that, there are few things better in this life than knowing a project you worked your ass off on for nearly two years and gone through four weeks of sheer chaos has finally come to fruition – just presented a poster on it and yes, the paper was accepted :D

[1] We submitted the paper written about our results and experiments from my UROP to a peer-reviewed journal, which is a collection of a lot of scientific experiments and results and discussion from a variety of fields.

[2] Peer reviewers are usually scientists within your field of study that can comment and criticize the work you submitted. They send back a round of comments that you should address when resubmitting to the journal.

[3] What ultimately was wrong with my computer was a broken heat sink and a virus that was affecting my computer’s bootup (basically hogging all the CPU such that my computer would overheat all the time on startup).

[4] Ssh means to remotely access a computer (so you can access another computer’s files from your own computer)