rseng-notebooks

# Notebook engineering Notebooks are where most research computing happens - and their superpower (interactive, stateful, out-of-order execution) is exactly their reproducibility hazard. The discipline is not "stop using notebooks"; it is knowing what notebooks are FOR (exploration, narrative, teaching) and applying engineering at the point where a notebook turns into infrastructure without anyone deciding it should. The CodeRefinery Jupyter lesson teaches the same split. ## Hidden state: the core hazard A notebook's on-screen code and its kernel's actual state can disagree: cells run out of order, deleted cells leave live variables, and a figure can come from code that no longer exists. Working rules: - Restart-and-run-all IS the test: before trusting, committing or sharing any notebook, restart the kernel and run top to bottom. A notebook that only works in one execution order is broken - fix the order now, while you still remember it. - Keep cells re-runnable: no cell should break when run twice (guard appends, recreations, cumulative mutations); avoid mutating a variable across distant cells - derive new names instead. - Definitions up top: imports, parameters and configuration in the first cells; a parameters cell makes intent explicit and enables parameterization later. - Watch execution counts: out-of-sequence numbers in a "final" notebook are the tell (rseng-version-control-review reviewers can see them too). ## Version control that works Raw...