How to think about the empirical aspect of research
Empirical research is not “running regressions.” It is building a credible bridge from variation in the world to a precise claim, and making that bridge strong enough to survive a skeptical referee.
1) Start with an estimand, not a specification
Before code, write down the object you want to study:
Causal estimand: the effect of (X) on (Y) (under a clearly stated intervention).
Descriptive estimand: how (X) and (Y) co-move (useful, but not causal).
Predictive estimand: forecasting (Y) (rarely the main goal in this course).
A regression is one possible estimator. The estimand is the research.
2) Identification is a story about variation
The core question is always:
Which variation identifies your claim?
In practice:
What moves your “treatment” variable?
Why is that movement plausibly unrelated to the outcome except through your channel?
What would break this argument?
If you cannot answer these three, you do not have an empirical design yet.
3) Assumptions are the price you pay for inference
Every design buys inference by paying assumptions. Your job is to:
minimize the assumptions,
state them clearly,
test their implications wherever possible.
For example, fixed effects do not “solve endogeneity.” They change the comparison!
4) Data construction is part of the design
In corporate finance, many results are driven by measurement and sample choices:
definitions (capital, liquidity, lending),
winsorization and missing data rules,
the sample pipeline (who enters, who exits, mergers, breakpoints).
A credible workflow produces:
a transparent construction pipeline,
a variable dictionary,
a one-command replication script.
5) Estimation and inference are engineering
Once the design is clear, implementation must be correct:
fixed effects reflect the comparison you want,
clustering reflects the correlation structure of shocks,
robustness checks target specific threats, not a grab bag of controls.
Code is not decoration: it is the proof that you estimated what you claimed.
6) Interpretation is economic, not statistical
“Significant” is not the endpoint.
Translate coefficients into:
units that matter (percent, bps, dollars),
plausible mechanisms,
magnitudes relative to benchmarks.
If you cannot explain a coefficient in one sentence, the design is not finished.
Referee-mode checklist (use this every time)
You are ready to show results only if you can answer:
What is the claim / estimand?
What variation identifies it?
Which assumption does the heavy lifting?
What diagnostic would convince you that you are wrong?
How to organize empirical workflow
A good empirical workflow is not “clean data → run regressions.” It is a repeatable pipeline that turns raw inputs into claims, with enough structure that (i) you can debug, (ii) you can extend, and (iii) someone else can replicate.
The principle: one button replication
Your project should have a single entry point:
run_all.R rebuilds everything from scratch (data → tables/figures → site).
If run_all.R breaks, the project is not yet research-grade.
Recommended project structure
Use a consistent folder layout:
data_raw/ — original inputs (never edited by hand)
data_clean/ — cleaned intermediate data (created by scripts)
code/ — scripts (numbered in execution order)
output/tables/ — exported tables (CSV/LaTeX)
output/figures/ — exported figures (PNG/PDF)
docs/ — rendered site (GitHub Pages target)
scratch/ — temporary experiments (safe to delete)
Rule: only data_raw/ is “source of truth.” Everything else is reproducible output.
The pipeline (design → data → estimation → reporting)
Organize scripts as a sequence:
00_setup.R
load packages, set paths, set seed, define global options
01_build_data.R
read raw inputs, clean, construct variables, write data_clean/master_panel.csv
03_estimation.R
main specifications, inference choices (FE, clustering), robustness targeted to threats
04_outputs.R
export model tables, export figures, save objects needed by the site
05_render.R
render the website / report
This is exactly how you keep analysis modular and debuggable.
“Logs” you should always produce
Every serious empirical project prints (and saves) the answers to:
What is the sample size at each filter step?
How many unique units (banks / firms) and time periods?
Are there duplicates in the panel key?
What is missing, and is it systematic?
What is the distribution of key variables (levels and changes)?
If you do not log these, you will waste days later.
Version control is part of the workflow
A clean Git routine:
commit after each meaningful, working change
commit messages describe what changed and why
keep large derived files out of Git (use .gitignore for data_clean/ if needed)
tag stable versions (e.g., v1_ta1_complete) so you can always revert
Dependency management (avoid “it works on my machine”)
Do not install packages inside scripts.
use renv (or equivalent) to lock package versions
record session info at the end of runs (sessionInfo())
The TA1 standard
In TA1, the workflow goal is:
Build a synthetic master panel once, then repeatedly reuse it for descriptives and fixed-effects models.
By TA2–TA6, you should still be using the same pipeline — you just add modules and extend the master dataset.
What is the most appropriate coding language for my project?
The “best” language is the one that minimizes total research cost: time to implement + time to debug + time to replicate + credibility with your audience.
Quick positioning
Stata: best for standard applied micro workflows and fast, conventional regression work; weakest for modern software engineering and large-scale data pipelines.
R: best all-around for econometrics + visualization + reproducible reporting; strong for high-dimensional fixed effects and modern causal packages.
Python: best for data engineering, web scraping, APIs, text/NLP, and scalable pipelines; econometrics is good but reporting and some “applied micro conventions” can be more work than in Stata/R.
Gretl: great teaching tool and lightweight econometrics; less common in top-tier research workflows and ecosystem is smaller.
Matlab: excellent for numerical methods, simulations, structural models, optimization; not the default for reduced-form empirical pipelines (data cleaning + causal inference + reporting).
What each one is “for” in practice
Stata
you want the quickest path from cleaned panel → conventional tables,
you are following a classic applied micro/corp-fin template,
your coauthors/advisors are Stata-native.
Watch-outs: less natural for reproducible research engineering (project pipelines, dependency mgmt), more friction for scraping, APIs, and complex text processing.
R
you want research-grade reporting (Quarto/Rmd) + clean figures + tables,
you need high-dimensional fixed effects and modern causal inference tooling,
you want to teach / enforce a transparent workflow (scripts + outputs + site).
Watch-outs:
some data engineering tasks are easier in Python (scraping, messy parsing),
performance can require care for very large datasets.
Python
you need web scraping, APIs, NLP, and messy data ingestion,
you want a scalable pipeline mindset (testing, automation),
you’re building datasets more than running canned regressions.
Watch-outs:
for “applied micro style” regression tables and FE-heavy work, you may do more manual setup than in R/Stata,
the ecosystem is broader, so conventions vary more across labs.
Gretl
you want a simple environment for classic econometrics and teaching,
you need something lightweight and transparent for small projects.
Watch-outs:
much smaller ecosystem; less common in corp-fin research replication packages,
fewer cutting-edge methods implemented as quickly as R/Stata.
Matlab
you are doing structural estimation, numerical optimization, simulations, dynamic programming,
you need high-quality linear algebra tools and controlled numerical workflows.
Watch-outs:
not the easiest default for data cleaning + causal inference + reproducible reporting,
fewer “applied micro defaults” than Stata/R.
A good rule for this course
For Finance 4 empirical TA work, the lowest-friction, highest-credibility stack is:
R as the main analysis language (econometrics + reporting + figures)
Git for version control
Python as an add-on when we move to web scraping / text (later topics)
If you personally live in Stata, a perfectly fine alternative is:
Stata for estimation + core tables, plus
Python (or R) for scraping and data construction, and
still Git for version control.
The only “wrong” choice
Mixing languages without clear boundaries.
Good mixes:
Python → R (Python builds data, R estimates/reports)
Python → Stata (Python builds data, Stata estimates/tables)
