Describe the destination.
Let Nix work out the journey.
A familiar Linux workflow is a sequence: install a package, tweak a file, upgrade a library. Two machines can drift apart even when you intend to configure them the same way. The history matters.
With Nix, you describe the inputs and how software is built. An environment becomes something you can keep in a file, review in Git, and recreate. You still use a terminal, processes, files, and your favorite editor. The change is how those pieces arrive.
Next section: Think recipes, not installation history.Think recipes, not installation history.
Imagine sending a colleague a recipe that names the compiler, source, and libraries instead of a list of commands that worked on your laptop. Nix uses that dependency graph to produce store objects. Compatible results can often be downloaded from a binary cache.
Reproducibility is a design goal, not a promise that every upstream build is bit-for-bit deterministic. Undeclared inputs, timestamps, hardware, and mutable application data still matter. Pinning inputs is one part of the solution.
A Nix environment is described by its inputs, rather than only by the history of the machine.