Managing Your Development Environment

How to set up, understand, and maintain a local development environment — for data science students.

The Mental Model Bootstrap a Machine Bootstrap a Project Troubleshooting

The goal here is not to memorize commands, but to build a mental model of what lives where on your machine and why.

Who this is for

Students who can open a terminal but feel uncertain about:

  • Where Python (or R, or Node) actually lives on their laptop
  • Why one project’s packages break another project
  • What an environment variable is and where to set it
  • How to recover when “it worked yesterday”

Learning goals

By the end of this guide, you should be able to:

  1. Describe the layers of your environment: OS → shell → language runtimes → package managers → project environments → IDE.
  2. Install and switch between language versions without breaking your system.
  3. Create isolated, reproducible project environments.
  4. Manage secrets and configuration through environment variables.
  5. Bootstrap a brand-new machine in under an hour.

The mental model

Before installing anything, understand the stack:

Operating System (macOS / Windows / Linux)
   └── Shell (zsh, bash, PowerShell)
        └── System package manager (Homebrew, apt, winget)
             └── Language runtimes (Python, R, Node, Julia)
                  └── Language package managers (pip, uv, conda, renv, npm)
                       └── Project environments (.venv, conda env, renv)
                            └── Editor / IDE (VS Code, RStudio, JupyterLab)

Each layer is replaceable, and better tools within each layer continually emerge. Problems usually come from confusing which layer you are working on.

Why Use a Shell?

A shell is the universal glue for open source tooling: nearly every data tool — Python, R, git, curl, jq, AWS CLI — reads text in and writes text out, and the shell lets you pipe them together into reproducible workflows. That text-first, composable model is what makes it possible to mix and match tools across projects instead of being locked inside one IDE or platform.

Going further

  • Containers (Docker, Dev Containers) for fully portable environments
  • Cloud notebooks (Colab, SageMaker, Posit Cloud) as fallbacks, not replacements
  • Dotfiles repos for sharing your config across machines