R For Research

What you actually gain

A complete record of the analysis. Every step exists as code. Six months later you can see exactly how a variable was recoded, which cases were excluded and in what order things happened. Point-and-click work leaves no such record, and reconstructing it from memory at write-up is a genuinely common source of trouble.

Correction without repetition. Find an error in an early step and you fix that line and re-run everything after it in seconds. The same correction in menu-driven software means repeating every subsequent click.

Access to methods that are not in the menus. Multilevel models, structural equation modelling, meta-analysis, Bayesian methods, specialised measurement models — these exist in R, usually first, because methodologists publish their work as R packages. If your analysis is at all unusual, R may be the only place it is implemented.

Publication-quality graphics. Figures are produced by code, so they can be regenerated when the data changes and adjusted precisely rather than redrawn.

Reproducible documents. Analysis and writing can live in one file, with results inserted automatically. When a reviewer asks for an additional case to be excluded, every number, table and figure in the document updates from one re-run. For a thesis with many results, this removes an entire category of transcription error.

The cost, stated honestly

R is harder to start with than menu-driven software, and pretending otherwise wastes people’s time.

You will spend the early weeks on things that have nothing to do with your research: getting data in, understanding why a column is the wrong type, deciphering error messages that assume you know what went wrong. Most people find it becomes comfortable somewhere in the first few months of regular use, but that is real time, and it is time removed from your actual project.

So the decision depends on where you are:

• Early in the doctorate, before data collection? Usually worth it. You have time to learn, the skill lasts beyond the thesis, and it is increasingly expected in academic job applications.
• Mid-project, analysis due in three months? Usually not, unless you need something R alone provides. Learning a new tool under deadline is how deadlines get missed.
• Your field expects it? Then it is not really a choice, and earlier is better than later.
• Your supervisor cannot help with it? Weigh that seriously. Being the only person in your group using a tool means every problem is yours alone to solve.

Using SPSS or Stata for a doctorate is entirely respectable. No examiner has ever criticised a thesis for the software it used, provided the analysis was appropriate and properly reported.

How the ecosystem works

R itself is fairly minimal; nearly everything is done through packages contributed by others. That is the source of both its reach and its main frustrations.

In practice most researchers work in RStudio rather than R directly — it provides the editor, the console, plots and file management in one place, and there is little reason not to use it.

The packages you need depend entirely on your field, and asking colleagues in your own discipline is more useful than any general list. Broadly, there are well-established packages for data manipulation and graphics, for structural equation modelling, for psychometrics and reliability, for multilevel models, for meta-analysis and for survey data. The methodological literature will usually name the package alongside the method.

Two practical cautions about relying on contributed packages:

• Quality varies. Packages published through the main repository meet basic technical standards, not standards of statistical correctness. Prefer packages that are widely used in your field, actively maintained and described in a peer-reviewed paper you can cite.
• Versions change. A package update can alter defaults or output between the analysis and the write-up. Record the versions you used — R can report them for you — and include that in your methods or an appendix. This is standard practice and takes one line.

Habits that prevent trouble

• Never edit the raw data file. Read it in, do everything in the script, write outputs elsewhere. The raw file stays exactly as collected.
• Comment as you go. Not what the code does — that is visible — but why you made the decision. Why these cases were excluded, why this transformation. That reasoning becomes your methods chapter.
• Set a random seed for anything involving randomness, including bootstrapping and multiple imputation. Without it your results change slightly on every run, which is awkward when a number in your thesis no longer matches the output.
• Restart and re-run the whole script periodically. Code that only works because of something still loaded in memory is a script that will fail when you need it most.
• Keep the script under version control, or at minimum keep dated copies. Being able to see what changed and when has rescued a great many analyses.
• Do not paste code you do not understand. The forum answer that produces a result may be answering a different question. You will be asked to explain your analysis, and “I found it online” is not an answer.

Reporting an R analysis

Name the software with its version, and name the packages you used for substantive analyses with their versions and citations. Most package authors provide a citation, and R will produce it for you — using it is expected practice, and it credits the methodologists whose work you relied on.

Include your script as an appendix or a supplementary file. This is increasingly common, costs nothing, and demonstrates exactly what was done. It also protects you: if a result is questioned, the script settles what was run.

What does not belong in the thesis is raw console output. Format results into proper tables in your discipline’s style, as you would with any other software. Code in an appendix; results in the reporting format your field expects.