Analyst, not a coder

(aka how to be an effective researcher)

Your job in gnlab is to analyze and answer questions about the world. Writing code is one small piece of answering questions. This might be a change from expectations in places where you have been a research assistant in the past or coursework you might have done. This page provides advice on the non-code aspects of being a successful analyst.

Understanding context

• One of the hardest parts of being an RA is that it is often difficult to understand the bigger picture: Why am I doing this task? How does it fit into the broader project? It is essential that you know the answers to these questions before you start working on the task.
• We try to communicate context five ways
  • Latest draft of slides or paper
  • Practice runthroughs
  • Objective at the top of github ticket
  • Project wiki
  • Live discussion at checkin
• If we haven't succeeded in explaining the context, please ask! A pet peeve of Peter’s from when he was an RA was being assigned work and not understanding how it fit in to the broader picture.

Getting stuck

Often when you are working on a problem you will encounter two options where you aren't sure what's the right choice. You are always welcome to ask a question and wait for feedback. Another option is to make a note in the github comment: "I had a choice between (a) and (b) and it wasn't obvious what to do. I provisionally made choice (a) for the following reasons, but glad to revisit." This allows you to surface parts of your work that you are uncertain about while still pushing forward with the analysis

Written output

Your first comment

An effective ticket comment usually includes

1. Choices you made (see "getting stuck" above)
2. statistical output (tables or figures)
3. written interpretation of the output
   • does this answer the assigned question?
   • does it make sense given what you know about the project more broadly?
   • does it make sense given what you know about the world?
4. (if ticket is not ready to close) next steps
   • if left to my own devices, this is what I would do next
   • here are some other options that I considered

Subsequent comments

Most of the time, we will ask for additional iterations of output. This is challenging because it bc it adds an additional variable: your answers might change. Here, a good response includes the three items above, together with:

5. Does the answer exactly replicate?
   • Did the numbers change a little bit, but the interpretation is the same? (we call this "numbers changing")
   • Did the numbers change a lot? (we call this "sentences changing" or "substantively changing")
   • If it isn't obvious already, why did the numbers change?

Clarity and proofreading

Here are some "rules" we think are helpful for all types of writing: academic papers, markdown memos, and github comments.

Clarity: Rule #4: No great paper—no matter how well constructed, brilliant, and well written—first emerged from the author’s printer in that form. It was rewritten at least 10 times. Rewriting is the true art of writing.

Proofreading: Rule #2: The insights of your paper will first be judged by how you present them. If your paper is written in an unprofessional manner, your empirical work, mathematical proofs, and models will be viewed with initial skepticism.

From The Ten Most Important Rules of Writing Your Job Market Paper

Here are some tips on how to implement rule #4 and rule #2 which we have found helpful.

Clarity

• Sketch your answer at the whiteboard (note: we aren't sure if your new workspace at Booth has a whiteboard... if it doesn't we are glad to work on acquiring one)

  • Would the ideas be more clear if you re-ordered them?
  • Are there logical gaps such that additional connecting sentences are needed?

• Identify and communicate to us potential weaknesses in your answer. Examples:

  • Missing data prevent us from addressing problem x
  • This is the first time I have implemented methodology y so it's hard for me to check my work
  • The work assigned doesn't provide a compelling answer to the objective in the ticket because of z
  • A skeptic would also really want to know about q to find this answer credible

Tips on Proofreading

• Print a hard copy
• Block external noise. Pascal has special headphones for this.
• Go to a place where no one will bug you. Peter likes to go to the fourth floor of Harris.

How much should I proofread?

• Your level of effort should be highest for longer products (e.g. a memo, whether written in markdown or google docs) and work products where the subject matter is complex.

"Live" summaries

• Sometimes during a weekly meeting, we will ask you to give an update to the rest of the lab (not just the PI who has been supervising your ticket) of what you are working on and what you have learned. When we do this, we recommend that you practice in advance at least once. Before we give a presentation, we usually practice it five times. When we were starting out in our careers, we practiced even more often than this.