Writing Reproducible Notebooks and Scripts

Why Reproducibility Matters

Reproducibility is the ability of another analyst — or your future self — to re-run your analysis on a fresh machine and obtain exactly the same output. In data science, a result that cannot be reproduced is a result that cannot be trusted. Industry certifications, including the IBM Data Science Professional Certificate, treat reproducibility as a core professional competency, not an optional nicety. Employers expect that deliverables handed off between team members, or submitted for audit, will run cleanly without undocumented manual steps.

The Two Biggest Threats to Reproducibility

Environment drift happens when your code depends on a specific version of a library that is not recorded anywhere. A teammate installs a newer version of pandas or ggplot2, runs your notebook, and gets different results or an outright error. The fix is to capture every dependency and its version before you share your work.

Hidden execution state happens when a Jupyter notebook has been run out of order — cell 10 before cell 3 — leaving variables in memory that a fresh run would never create. A notebook that produces correct output in its current session but fails on a clean restart is not reproducible. Always restart the kernel and run all cells top-to-bottom before declaring a notebook complete.

Managing Python Environments with requirements.txt

A `requirements.txt` file is a plain-text list of every Python package your project needs, pinned to an exact version. You generate it inside your active virtual environment with:

```

pip freeze > requirements.txt

```

A collaborator who clones your repository recreates the same environment with:

```

python -m venv env

source env/bin/activate # Windows: env\Scripts\activate

pip install -r requirements.txt

```

Keep the file in the root of your repository alongside your notebooks. Without it, environment setup becomes guesswork.

Structuring a Reproducible Jupyter Notebook

A well-structured notebook reads like a technical report. Apply these practices:

1. One imports cell at the top. All `import` statements go in the first code cell so every dependency is visible immediately.

2. Relative paths only. Never hard-code a path like `C:/Users/maria/Desktop/data.csv`. Use relative paths such as `../data/sales.csv` so the notebook works on any machine where the repository structure is intact.

3. Markdown between every major section. Add a Markdown cell above each logical block explaining what the code does and why. This turns a script into a narrative.

4. Functions instead of repeated code. If you copy and paste a block of code more than once, wrap it in a function. Place all helper functions in an early cell or, for larger projects, in a separate `.py` module that the notebook imports.

5. Restart and run all before sharing. Use Kernel → Restart & Run All and confirm every cell completes without error.

Writing Reproducible R Markdown Reports

R Markdown combines prose, code, and output in a single `.Rmd` file that is knitted into HTML, PDF, or Word. Because knitting always executes code in a clean R session from top to bottom, an R Markdown report is naturally more resistant to hidden-state problems than an interactive session.

Key practices:

• Set a random seed. Any analysis that involves random sampling, splitting data, or modeling must call `set.seed()` with a fixed integer near the top of the document. Without a fixed seed, outputs like train/test splits or bootstrap estimates will differ between runs.
• Use relative paths. The same rule that applies to Python applies here. The `here` package (`here::here("data", "file.csv")`) is a reliable way to build paths relative to the project root regardless of the working directory.
• List package versions. Include a `sessionInfo()` call in a final code chunk so readers can see the exact R and package versions used.
• Knit to verify. Knit the document yourself first; then have a second student knit it on their machine and compare the HTML output. Identical output confirms reproducibility.

Version Control as a Safety Net

Git and GitHub are not just for software developers. Committing your notebook and all supporting files — data (if small), `requirements.txt`, and the `.Rmd` file — creates a timestamped record of every change. If a partner cannot reproduce your results, you can both check out the same commit and eliminate version differences as a cause. Use `.gitignore` to exclude large data files, virtual environment folders, and rendered HTML that should be re-generated locally.

Lab Safety and Data Handling

Data science labs do not involve physical hazards requiring PPE, but professional data handling standards apply. Never commit real personal or proprietary data to a public repository. Use anonymized sample datasets for all lab exercises. If a dataset contains identifiers, remove or mask them before sharing. Treat credentials (API keys, database passwords) as secrets: store them in environment variables or a `.env` file that is listed in `.gitignore`, never hard-coded in a notebook cell.