Building a Data Science Stack That Won't Fall Apart
Most people spend way too much time configuring their environment before they write a single line of model code. I watched a team burn three days just deciding between conda and venv while the project deadline moved closer. The stack itself isn't the hard part. Knowing what to leave out is. At the core, you need four things: a language, a package manager, an execution environment, and version control. Python is the default. It has the ecosystem. R is fine for statistics-heavy work but the deployment story is weaker. NumPy and Pandas handle data. Scikit-learn covers the basics. For deep learning, pick one framework and commit to it. I've seen people try to run both PyTorch and TensorFlow in the same environment and waste half a day on CUDA version conflicts that manifest as silent numerical mismatches rather than hard errors. The package manager choice matters more than beginners realize. Conda creates isolated environments and handles binary dependencies like CUDA drivers and MKL libraries. Pip alone won't do that cleanly. If you're doing GPU work, conda or Docker is essentially mandatory. I use a combination: conda for the base environment and virtualenv on top when I need tighter isolation between projects.
Jupyter or VS Code for development. Jupyter is fine for exploration but you should never ship code from it. The habit of writing cells and expecting them to translate into production scripts is how you end up with undeliverable projects. I keep notebooks strictly for exploration and move anything reusable into .py modules before anyone asks for the code.
Setting It Up Without Overthinking
Here's the practical sequence. Install Miniconda first. It's lighter than the full Anaconda distribution and includes everything you need. Then create an environment with pinned Python and the core libraries. Something like: conda create --name ds python=3.11 numpy pandas scikit-learn jupyter matplotlib That's it. Don't add everything at once. Start with what the project actually needs and add from there. I've lost count of how many environments on my machine have 47 packages installed because I was "preparing for something that might come up." Nine of those packages haven't been used in two years and they slow down dependency resolution for nothing.
Get the Full Details
After that, set up Git. Not optional. Every dataset, every script, every model version should be trackable. I use a simple structure: a project root with data/, src/, notebooks/, and models/ directories. The data folder stays out of Git because it's large and shouldn't be versioned. Instead I put a small sample in there and keep the real data in S3 or a similar store with a script that pulls it on demand.
A Problem I Actually Ran Into
Last year I inherited a project where the original developer had installed CUDA 11.8 through pip alongside a conda-managed PyTorch that expected CUDA 11.7. Everything appeared to work. Models trained. Accuracy looked fine. But when I tried to deploy to a staging server with a different GPU driver, the inference results were off by small amounts that accumulated into wrong predictions on edge cases. The bug took four hours to find because there were no error messages. Just quietly wrong numbers. The fix was straightforward but the lesson stuck: pin your CUDA version explicitly in the conda environment file and verify it matches the target deployment hardware before you ship anything. I now always run a quick smoke test on the target environment before considering a project done. Two lines of Python that check the CUDA version and run a trivial tensor operation catch this stuff immediately.
What People Get Wrong About This Stack
There's a common belief that adding more tools makes you more productive. In practice it does the opposite. Every new library introduces dependency conflicts, documentation to learn, and maintenance overhead. A lean stack with three well-understood tools beats a bloated one with ten half-mastered ones every time. I've seen senior engineers who know Python, Pandas, scikit-learn, and Git build better systems than people juggling twelve frameworks but shipping nothing. Another thing: people treat environment management as a one-time setup task. It isn't. Environments rot. Packages get updated. Dependencies break. I keep an environment.yml file for every project and update it weekly. It takes maybe ten minutes and saves hours when you need to reproduce something three months later.
Data Science Stack Limitations You Should Accept
This approach has real constraints. It doesn't scale well past a certain point without introducing orchestration tools. Once you have more than five people working on the same codebase, simple Git and conda aren't enough. You need CI/CD pipelines, containerization, and perhaps aMLflow or similar tracking. But that's a different problem space. For a single person or a small team, the conda-plus-Git setup covers most needs without the overhead of enterprise tooling. Reproducibility is another weak spot. Even with pinned environments, you can't guarantee identical results across different hardware. GPU floating point behavior varies between architectures. If exact reproducibility matters for your work, you'll need to lock GPU drivers and cuDNN versions too, and even then there are edge cases where randomness in cuBLAS algorithms produces different bit patterns on different hardware. This is why scientific workloads often run on CPU for validation even when training happens on GPU. For deployment, this stack alone gets you nowhere near production. You'll need Docker, possibly Kubernetes, and a serving framework like FastAPI or TorchServe. But that's post-development work. Don't mix deployment concerns into your development environment. Keep them separate until you actually need to ship something.
The short version is: start simple, pin versions, test on target hardware early, and resist the urge to add tools you don't need today. The stack you build tomorrow will thank you.
