Future You Is a Stranger. Be Nice to Them.

Reproducibility gets talked about as an ethical position, which is true but not very motivating at 11pm. Here is the version that actually changed my behaviour.

In six months, a reviewer will ask you to rerun an experiment with one change. You will open the folder. It will contain final_v2.py, final_v2_REAL.py, and a results file whose number you cannot reproduce with any of them. The person who made that mess was you, and they are now unreachable.

Reproducibility is mostly a favour to yourself, delivered late.

The minimum that is worth doing

Set the seeds. All of them. Python, NumPy, and your framework each have their own. Put it in one function, call it first, and never think about it again.

def set_seed(seed=42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed)

Note that this makes runs reproducible, not correct. If your result only exists at seed 42 and collapses at seed 43, you have not found a finding, you have found a coincidence. Run several seeds and report the spread. A mean with a standard deviation is worth more than a single glorious number, and reviewers know it.

Pin your versions. "It worked in June" is not a dependency specification. A requirements.txt with actual version numbers takes two minutes and saves entire afternoons.

Commit before every experiment. Not for elegance, but so that a result can always be traced back to the exact code that produced it. If a number is in your paper, you should be able to point at the commit that made it.

Keep a log. Plain text is fine. What you tried, what happened, what you concluded. The most valuable entries are the failures, because in four months you will have a clever idea and the log will quietly inform you that you already had it, and that it did not work.

The one that people skip

Write the README before you think you need it. Not a beautiful one. Just: what this repo does, how to install it, how to run the main experiment, what output to expect.

If you cannot write those four things clearly, that is useful information about the state of your project.

Publish the code anyway

It is never as clean as you want. Publish it. Someone reading imperfect real code that actually produced the paper is far better off than someone reading nothing, and a link to a working repo does more for your credibility than another paragraph of prose ever will.