Get this right once and you no longer have to worry about it. The goal is not to use the fanciest tool. It's to remove friction between you and the data.

<aside> 🧭

Who this page is for: anyone wanting to setup a dev environment. Follow it top to bottom and you'll finish with an editor, Python, a working project environment and Git connected to GitHub. Already comfortable with terminals and virtual environments? Skip to the Starter checklist at the bottom.

</aside>

Before you start: the terminal

Most setup happens in the terminal: a window where you type commands instead of clicking buttons. You only need a handful of commands on this page, and each one is explained.

Type each command exactly as shown, then press Enter. Where a guide shows a $ at the start of a line, that is the prompt, not part of the command: don't type it. For a wider set of commands, see the Terminal & Command Line Cheatsheet.

Editors and IDEs

Tool Best for Tier
VS Code (recommended default) Everyone: flexible, a huge extension ecosystem, and free Junior to Senior+
PyCharm Data engineers writing serious Python: best-in-class debugging, dbt Core integration Mid to Senior+
DataGrip / DBeaver SQL-heavy work across multiple databases. DBeaver is free; DataGrip is JetBrains-paid Junior to Senior+
Jupyter / JupyterLab Exploratory analysis and notebooks: still the default for ad-hoc work Junior to Senior+
Cursor AI-native editing, useful once you can already judge whether the AI's output is right Mid to Senior+

If you only pick one: VS Code. Add the SQL formatter, Python, Jupyter, GitLens and dbt Power User extensions, and you've covered 90% of both tracks.

Python environments: what "don't install packages globally" means

A package is code someone else wrote that you install and reuse, such as pandas or requests. Installing a package globally means installing it into the one copy of Python your whole computer shares.

That causes three problems:

  1. Projects clash. An old project needs pandas 2; a new one needs pandas 3. There is only one global slot, so upgrading for one project breaks the other.
  2. You can damage your system. macOS and Linux use Python for their own tools. Overwriting their packages can break things that have nothing to do with your code.
  3. Nobody can reproduce your work. Your project silently depends on whatever happens to be installed on your laptop, so it fails on a colleague's machine or a server.

The fix is a virtual environment: a private, self-contained copy of Python for each project, stored in a folder called .venv inside that project. Packages you install go into that folder only. Think of it as a separate toolbox per project, rather than one shared drawer everyone rummages through.

flowchart LR
  subgraph G["Global install: avoid"]
    A1["Project A"] --> S["One shared Python<br>pandas 2 or 3?"]
    B1["Project B"] --> S
  end
  subgraph V["One environment per project"]
    A2["Project A"] --> VA[".venv<br>pandas 2"]
    B2["Project B"] --> VB[".venv<br>pandas 3"]
  end