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 motivation

• 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
  • Objective at the top of github ticket
  • Live discussion at standup
  • Weekly meeting
  • Practice runthroughs
• If we haven't succeeded in explaining the motivation, 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.

Titling exhibits

Add a title to every table and figure you make with what you think the key lesson is.*

Think back to the motivation. Does your current draft of the exhibit answer the motivation? Why or why not? If not, consider mentioning this in your github comment or memo.

*The one exception is that if you know for certain that an exhibit is going in a slide deck or paper then omit the title. But this is true for < 10% of the exhibits that we make.

Getting stuck

It is normal to get stuck. At the same time, we put a high premium on working autonomously. When you are unsure between two choices, you can

1. ask us and wait for feedback
2. make a choice your self and include 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.

When possible, we prefer path (2) because this allows you to surface parts of your work that you are uncertain about while still pushing forward with the analysis

Level of polish

A constant tradeoff in writing code and prose is that having good style is time consuming. How much time to invest in style and polish?

• For github comments and memos: more time for longer work products, more time where the subject matter is complex. Always proofread memos and material written for appendices of papers.
• For code: writing sloppy code is called going into "technical debt". Code that is merged to main must follow the style guide (and therefore not be sloppy). Debt has pros and cons. Be thoughtful about whether to go into debt.

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.

Going in depth on hard problems

At times, we will give you hard problems to work on. The more you work independently and propose creative solutions the better. "Going deep" is obviously useful because it improves the research, but it also has professional development benefits. First, you will learn more by independently solving a problem. Second, if you are applying to grad school, it will be easier for us to write you a strong letter of recommendation which illustrates your brilliance because we will have better and more concrete examples to point to.

---

Written output (not discussed at retreat but still live)

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? (compare to what you find via google)
4. Next steps (if ticket is not ready to close)
   • 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?

Architecture of comments

For longer comments, it should be easy to quickly get the main takeaway with a TLDR.

The "details" part of a comment should be easy to skim. Use section headers, bolding and underlines. This guide shows how to write skimmable comments.

Troubleshooting bugs

When we ask you to find and/or fix a bug, please tell us how the bug arose and how you fixed it, rather than just that you fixed it.

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

---

Deprecated material

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