Why code?
A table arrives by email. You sort it, delete a few odd rows, copy two columns into a fresh sheet, drag a formula down, and twenty minutes later a number appears: 4.7. You paste it into your report and close the laptop.
Three weeks later the sender writes: sorry, that file was incomplete — here is the corrected version.
Now the real question arrives. What exactly did you do?
Not roughly. Exactly. Which rows did you drop, and why? Did the formula cover all of them? Was 4.7 a mean or a median? You will probably redo the twenty minutes, get 4.9, and never quite know whether the difference came from the new data or from a different click.
A script answers that question in seconds. It is the twenty minutes, written down. Swap the file, run it again, and the new number appears together with the complete account of how it was produced.
That is the whole argument, and it has little to do with being technical:
- Transparency. Every decision is written down, including the ones you would rather forget.
- Reproducibility. The same input gives the same output — tomorrow, on another machine, for a reviewer.
- Repetition without cost. Two hundred files, twelve countries, a new year of data: the same code, run again.
- Correction. Mistakes become visible, and therefore fixable. A wrong click leaves no trace; a wrong line does.
Code also fits the way this book tries to learn. A graph or a model summary is the view at the surface. The code is how we dive to see what produced it — and, just as importantly, how we come back up.
A result is a claim. The code is the evidence.
Amazing Fact
In 2010 the economists Carmen Reinhart and Kenneth Rogoff reported that countries with public debt above 90% of GDP suffer sharply lower growth. The finding travelled fast: it was cited in budget speeches across Europe and the United States during the austerity debates.
In 2013 Thomas Herndon, then a graduate student, asked for the original spreadsheet as part of a course assignment. He found that the formula for the average had been dragged over a range that stopped five rows short — Australia, Austria, Belgium, Canada and Denmark were simply not in the calculation.
Nobody had been able to check it before, because there had been nothing to check.
Why R?
This book uses R.
Almost everything here could also be done in Python, and several things could be done in Stata, SPSS or Julia. The choice that matters is not which language wins. It is the choice of an open language over a closed, point-and-click program — a place where you can read the source, install what you need, and keep working after your licence, your university account, or the software company itself has gone.
R was built by statisticians for data analysis, and it shows. Vectors, data frames, missing values, factors and models are part of the language rather than add-ons. Around it grew an unusually generous ecosystem: packages for cleaning, visualising, modelling, mapping, text, surveys, teaching — and for writing books.
This eBook is one of them. It is written in R Markdown and built with Bookdown, which is why the exercises you are about to meet run inside the page.
Why the tidyverse?
Most of the data work in this book uses the tidyverse, a family of packages that share one design.
The appeal is readability. filter(), select(), mutate() and summarise() are verbs, and a chain of them reads almost like a sentence about the data. Beginners can often follow what a piece of code is trying to do long before they understand every technical detail — which is exactly the surface view we want first.
But the tidyverse is not the boundary of the ocean.
Base R appears whenever it is shorter or clearer. Model functions come with their own syntax, specialised packages have their own conventions, and mathematical notation says some things better than any code can. The aim is not loyalty to one dialect. The aim is an analysis that is understandable, reliable and useful.