How to organize your computer for data work

Photo by Zulfugar Karimov on Unsplash

A computer used for data analysis should not become a maze of downloads, unnamed scripts, duplicated data sets, and mysterious files called final_v2_revised_REAL.csv.

A simple and consistent project structure makes analysis easier to reproduce, easier to share, and much less stressful to revisit months later.

This guide introduces a practical organization system built around projects, working directories, and version control. The examples use RStudio, but the underlying principles apply to many data-analysis environments.

Projects and working directories

R users often organize their work with RStudio projects. An RStudio project is represented by a file ending in .Rproj. The folder containing that file is the project’s working directory.

The concept of a working directory is about as important as it gets.

The working directory should contain everything needed for one coherent piece of work: data, scripts, documentation, figures, tables, and other outputs. And when I say everything, I mean it.

Opening the .Rproj file starts RStudio in that directory, which means relative paths work consistently without repeatedly calling setwd().

You can inspect the current working directory in R with:

getwd()

The exact path will differ across computers. The important point is that the project itself establishes the root from which files are referenced.

Why relative paths matter

A path relative to the working directory, such as input/survey.csv, can work on another person’s computer after they clone or download the project.
A path such as /Users/name/Documents/project/input/survey.csv usually works only on the computer where it was written.

A sensible folder system

You do not need one universal arrangement for every project, but consistency helps.

One practical approach is to keep local projects and version-controlled projects in clearly named parent folders, for example:

Documents/
├── local_projects/
└── github_projects/

The distinction between local and version-controlled is organizational rather than technical. A project can be moved into version control later, and a Git repository does not need to live in a specially named folder. The goal is simply to make projects easy to find.

Inside each project, create a small set of purpose-specific folders:

my_project/
├── input/
├── scripts/
├── output/
├── README.md
└── my_project.Rproj

A useful division of labor is:

input/ stores source data and any documentation needed to understand them.
scripts/ stores code used to import, clean, transform, model, or visualize the data.
output/ stores generated tables, figures, processed data, and model results.
README.md explains the project’s purpose, structure, and setup requirements.

For larger projects, you can refine this structure further:

my_project/
├── input/
│   ├── raw/
│   └── processed/
├── scripts/
├── output/
│   ├── figures/
│   ├── tables/
│   └── models/
├── report.qmd
├── README.md
└── my_project.Rproj

The distinction between raw/ and processed/ data is especially useful. Raw data should remain unchanged whenever possible; scripts should produce the processed files used for analysis.

Creating an RStudio project

To create a project in a new directory:

Open RStudio.
Choose File > New Project.
Select New Directory.
Choose the project type you need.
Enter a short directory name without spaces.
Select the parent folder where the project should live.
Click Create Project.

RStudio creates the directory and places an .Rproj file inside it.

The next time you work on the project, open that file rather than opening RStudio first and manually navigating to the folder.

Projects are not limited to R

An RStudio project can contain Python scripts, Quarto documents, SQL files, shell scripts, and ordinary Markdown.
The .Rproj file is simply a convenient way to establish the project root and manage an RStudio session.

Keep reports close to their inputs

A Quarto document can sit at the root of the project:

my_project/
├── input/
├── scripts/
├── output/
├── report.qmd
└── my_project.Rproj

This arrangement keeps common relative paths straightforward:

read.csv("input/survey.csv")

There is nothing wrong with placing reports in their own folder, especially in a large project. For beginners, however, keeping the primary report at the project root reduces path complexity.

Use version control instead of an `old` folder

It is tempting to preserve every earlier script by moving files into folders called old, archive, or backup. That is safer than deleting work blindly, but it quickly creates confusion about which version is authoritative.

A better long-term solution is Git, a version-control system that records changes to files over time. Git lets you recover earlier versions without keeping many manually renamed copies.

GitHub is a hosting service for Git repositories. It is useful for:

Preserving a remote copy of a project.
Collaborating with colleagues.
Reviewing changes.
Sharing code and documentation.
Publishing open research materials.

A GitHub repository is not automatically a complete backup strategy, and sensitive data should never be uploaded carelessly.

Still, Git and GitHub are much safer and clearer than relying on filenames such as analysis_final_final2.R.

Creating a GitHub-backed project

One straightforward workflow is:

Create a new repository on GitHub.
Decide whether it should be public or private.
Clone the repository to your computer using GitHub Desktop, the command line, or an IDE.
Open RStudio.
Choose File > New Project.
Select Existing Directory.
Choose the cloned repository folder.
Create the project.

The folder is now both a Git repository and an RStudio project.

Learn Git separately from GitHub

Git is the version-control system; GitHub is one service that hosts Git repositories.
The Software Carpentry lesson Version Control with Git is a good beginner-friendly introduction.

A few durable habits

The exact folder names matter less than the habits behind them:

Keep one coherent project in one directory.
Use relative paths.
Separate source data from generated files.
Generate outputs through code rather than manual editing.
Document the project in a README.md file.
Use Git to preserve history.
Avoid committing credentials, confidential data, large generated files, or machine-specific caches.

A tidy project will not make the analysis correct by itself. It will, however, make mistakes easier to detect, results more readily reproducible, and collaboration much easier.

Suggested citation

APA

Alvarado-Mena, E. (2026, July 28). How to organize your computer for data work. AlvaradoCSS. https://www.alvaradocss.com/posts/organize-data-projects/

Chicago

Alvarado-Mena, Edwin. “How to organize your computer for data work.” AlvaradoCSS. Originally published November 14, 2024; last modified July 28, 2026. https://www.alvaradocss.com/posts/organize-data-projects/.

Bonus track

Rendering professional documents with Quarto