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 four ways
  • Latest draft of slides or paper
  • 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.

Written output

Your first comment

An effective first ticket comment usually includes

1. statistical output (tables or figures)
2. 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?
3. proposed next steps, if ticket is not ready to close.

Iterating in 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:

4. Did the answers change at all?
   • Did the numbers change a little bit, but the interpretation is the same?
   • Did the numbers change a lot? If so, why?

Writing and proofreading

• The economics profession assesses whether your analysis is correct in part by whether your writing is clear and your attention to detail.
  • We spend a ton of time writing and rewriting our papers, our slides, and our responses to referees.
  • You should have the same high standards for github comments and markdown memos.
  • Before you submit work, ask yourself "is there some way that I could explain this more clearly?"
• We recommend finding a quiet physical and mental space where you can proofread your work before submitting it.
  • Both Pascal and Peter will print hard copies before passing a draft to the other PI
  • Peter likes going to the fourth floor of Harris to proofread
  • Pascal likes to wear headphones

"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.