2026-09-09 –, Ballroom All times in US/Pacific
Every project starts with a dev environment that works on your own machine. But the moment you try to share with a teammate, anything can (and does) happen. The first solution that most people try is container-based development, but even though this solves the reproducibility problem, it's a horrible developer experience. Another solution that people try is a virtual environment (venv, nvm, rbenv), and they're great, but if you have a polyglot app things start getting cumbersome again (and none of these help you manage system dependencies).
In this talk, we'll go over the tradeoffs between reproducibility and developer experience on an engineering team, and talk about a third solution that the audience should consider: Nix. Nix treats your dev environment as code, all the way down to glibc. We'll show how nix develop can give you a development environment that's reproducible across operating systems and ecosystems, while still giving you access to your development tools. But we'll also be honest about the complexities of Nix, as there are good reasons why not everyone is using it today to manage their development environments.
The talk follows a journey most engineers have lived, with a tradeoff at each stop:
- Local setup: fast and native until anyone on a different OS (or a new laptop) tries to run it
- Containers: reproducible but isolated from your IDE, debugger, and local tooling
- Virtual environments (venv, nvm, rbenv): great DX, but ecosystem-specific (not great for polyglot apps, especially if you need to manage system dependencies too)
- Nix: define your development environment as code (all the way down to glibc) for maximum portability across operating systems
The closing slides show a minimal flake.nix for a polyglot project, what nix develop gives a team in practice, and a few caveats about Nix's learning curve. We won't go into depth, but we'll include some resources at the end for people who want to learn more about Nix.
Daniel is a product designer and Oregon native. By day he works at Flox on developer tooling for environment and package management. By night he spends his time training for and running ultramarathons. He's tried using AI to code and run at the same time, with mixed results.