Over the winter break I spent some time reflecting on the past year, and I came up with three insights/research techniques that I want to start/keep using in 2021. My long term goal is to emerge from the PhD program with better problem solving skills, so I am trying to keep track of the times when I hit upon a research method or strategy that seems to work well. These three techniques are:

• Record your work (especially computer-based work) as you go in a Google Slides document.

• When you get an unexpected result, spend some time looking at that result and understanding it before tweaking things.

• Prototype quickly and often.

Let me go into some more detail on both points.

Recording Work as You Go

One thing that I started doing in 2020 was to keep track of work I was doing (especially programming or simulation) on slide decks. This was a practice that I started separately from maintaining a hardcopy of a lab notebook. I began to use Google Slides specifically to track projects that were mainly computer-based. This was really helpful for several reasons, the first being that it was simply more convenient to dump screenshots, code and outputs onto a slide deck than to print them all out and stick them in my notebook.

The slides had an additional benefit, which was that they forced me to be more deliberate and rigorous in how I worked. The slides became a living document that I tried to update throughout the day as I worked, just like I would do with my lab notebook at the bench. This notetaking helped me track my thinking, debugging and problem solving in real time. And because this practice forced me to articulate what I was doing at any given moment, it helped me think through my process and make sure that I was moving logically through the problem-solving process.

This electronic lab notebook also became an important tool when I was meeting with colleagues or presenting my work. When meeting with other people on my research team, I could use the slides to show what I had tried. And if someone asked me “have you tried this?” then I could go back through the deck and check definitively if I had done it and what the outcome had been. The raw data and images in the slide decks also became raw material for presentations I had to give. It was much easier to create documents for my class projects, weekly meetings, and lab presentations because I could just copy images over from my slides. It was also much easier for me to communicate the details of what I was doing when I was thoroughly documenting everything along the way.

One aspect of this practice that I know needs improvement is that I need to remember to copy the commands I was writing in Terminal onto my slides. There was one occasion near the end of the fall semester where I could not re-do an analysis that I had run earlier, and I think it was because I had forgotten what combination of commands and files I had used before. I need to remember to make note of these commands as well. I’m not always sure where to save them because I have multiple repositories of code, including scripts saved on my desktop, gists on Github, and lab protocols with detailed code included. Since my personal record-keeping on this front is a little haphazard, sometimes the commands fall through the cracks in my documentation system because I don’t have a defined place to put them.

Another thing that I need to work on is making sure that my written record is very detailed. Now that I’m back from winter break, I am trying to pick up my work again and there are a couple of diagrams and images that I am now struggling to interpret because I didn’t explain them in enough detail to myself while it was fresh in my mind.

Overall, being more disciplined in recording all my work as I go, hour by hour, has been extraordinarily beneficial for multiple reasons. But it also helps me with the second technique that I am trying to develop, which is refining my ability to understand and debug problems.

Taking Time to Understand the Problem

The other thing that I want to be more intentional about doing this year is to spend more time on understanding problems before I start trying to fix them. I caught myself several times last year seeing a result that I didn’t expect, and then deciding immediately that it was erroneous and required (random) changes in my codebase. Part of the scientific method is to interpret the results of an experiment, regardless of whether you think it’s wrong or not. I want to spend more time interpreting the results of my experiments so that I can learn all I can from them, before making more changes to my experimental process. I also need to be willing to pause when I see some output that I think is a problem and ask: is this really a problem? And if so, why? What might be causing it? How could I fix it?

In Cracking the Coding Interview, Gayle Laakmann McDowell lays out the troubleshooting process for software testing, and I think that it has a lot of valuable aspects to it even if you’re not writing code [1]. First, you need to understand the situation by asking a lot of questions. Next, you should understand the program (or experiment) that you are debugging, and break it down into steps. You can then test each step - maybe by checking to see if the output of that step matches your hypothesis or manual calculations - and at some point you should be able to identify the step where something goes wrong [1]. I really like this logical, thorough debugging process and I want to adopt it in my research going forwards.

In addition to taking more time in thinking about problems and bugs when I encounter them, I also just want to solve more problems this year, thanks to some advice from an amazing professor.

Prototype Quickly and Often

In 2020 I was really lucky to talk to Prof. Chelsea Finn (a leading researcher in AI and robotics) and one of the things I asked her was how to make the most of a PhD. She explained that one thing that worked well for her was that she would build and test things rapidly. She was not afraid to try things out in code and see what happened. (Sure, maybe that’s easier if you’re working in code than at the bench, but the idea still stands.) That idea really stuck with me because I am not comfortable “playing” with code or convolutional models or really anything that isn’t Legos or duct tape. I tend to feel afraid and anxious when trying new things and writing new code. I fear encountering my own inadequacies when my code inevitably breaks and I have to fix it. I don’t want to find out I don’t understand things very well. I am afraid of encountering the limits of my knowledge and problem solving abilities.

To give an analogy which is also a niche reference and a little silly, writing code for a new AI model feels a lot like I imagine Avatar Korra felt after battling with Zaheer in season 3 of The Legend of Korra. After the battle with Zaheer, she was terrified of using her full powers and returning to her role as avatar because the fight had been so traumatic that she didn’t want to feel that way again [2]. I know writing code for a graph neural network is not the same as airbending against a power hungry megalomaniac, but I understand where Korra was coming from. I also feel incredibly reluctant to really stretch out and try new things, because I’m just so terrified of feeling stupid.

…But that’s the whole point of the PhD! That’s why I came here! In 2021, I want to challenge myself to feel this way more often because those moments where I feel the most anxious and uncomfortable about trying something new are also the times when I learned the most in 2020. I want to challenge myself to battle Zaheer!

Figure 1 - Source [3]

References:

[1] Laakmann McDowell, G. Cracking the Coding Interview, 6th edition. 2016. CareerCup, LLC.

[2] Dante DiMartino, M. and Konietzko, B. “The Legend of Korra.” Nickelodeon. 2012-2014.

[3] Alexander, J. “Avatar sequel The Legend of Korra will be available to stream on Netflix in August.” The Verge. 21 Jul 2020. https://www.theverge.com/2020/7/21/21332813/legend-of-korra-streaming-netflix-avatar-last-airbender-nickelodeon-cbs-all-access Visited 11 Jan 2021.