Stop Installing Things Globally
A global Node or Python install feels convenient right up until you have two projects that need different versions of the same runtime, and one of them starts throwing errors that have nothing to do with your code. Use a version manager instead: nvm for Node, pyenv for Python, asdf if you'd rather manage everything through one tool. The extra setup step at the start pays for itself the first time you switch between an old project and a new one without breaking either.
Pin Your Versions, Don't Guess Them
An .nvmrc or .python-version file in the repo root means anyone who clones it, including future you on a new machine, lands on the exact version the project expects instead of whatever happens to be installed. Commit your lockfiles too: package-lock.json, poetry.lock, Cargo.lock. "Works on my machine" is almost always a version mismatch wearing a different problem's name.
Keep Secrets Out of Your Shell History
Environment variables belong in a .env file that's gitignored from day one, not typed inline in a terminal command where they end up in your shell history and your screen recordings. A tool like direnv loads them automatically when you enter the project directory and unloads them when you leave, so you're never one stray env command away from leaking a key into a log.
Containers Are for Parity, Not Everything
Docker earns its place when you need your local database or message queue to match production closely enough that "it worked locally" actually means something. It's a worse choice for your day-to-day editor and language tooling if the extra layer just slows down your feedback loop. Use it where drift between local and prod would actually bite you, and skip it where it's just ceremony.
Automate the Boring Setup
A new contributor, or you, six months from now on a fresh laptop, shouldn't have to reconstruct your setup from memory or a stale wiki page. A short setup script, even just a Makefile target or a couple lines of bash, that installs dependencies, copies the example env file, and runs the first migration turns "getting started" into one command instead of an afternoon.
Your Editor Config Should Travel With the Repo
An .editorconfig file and a shared linter or formatter config, ESLint, Prettier, Black, whatever fits the language, keep indentation and style decisions out of code review entirely. Without them, environments quietly diverge one contributor at a time, and you end up debating tabs versus spaces in a pull request instead of the actual code. Commit the config once and nobody has to think about it again.