How We Finish.

Every result traces to a config.

A number in a table that nobody can regenerate is not a result; it is a rumour. Every figure, every row, every ablation traces back to a configuration and a commit that produces it. The shape is ours to pick: a folder of YAML files, a tracking table, a notebook. The demand underneath does not move. Anyone in the group, and anyone who reads the paper in five years, can take the config and get the number back. People will ask. (I still answer questions about code I wrote as a student.) Build so the answer is a file, not an afternoon of archaeology.

Nothing important lives on one laptop.

Commit it. Push it. Put the results where we agreed they live, not where they happened to land. Work that exists only on your machine does not exist for the group; it is one spilled coffee away from not existing at all. The moment an experiment matters, it belongs to all of us, which means it belongs in the repository and the shared storage today, not once the campaign is done.

Keep the campaign legible.

A project is not a pile of runs; it is a story we can read. Keep a living record of what is running and why: owner, commit, path, result, what we learned, where it lands in the paper. Whatever columns we choose, the test is the same. Someone who was not in the meeting can read the record and understand the shape of the whole project. If they cannot, the record is decoration, not documentation.

Call the freeze, out loud.

When the results are good enough to tell the story, we stop, and we say we are stopping. The experimental freeze is a decision, made together and made explicit. A freeze nobody announced is the reason papers churn for months and still arrive late.

After the freeze, we write.

A frozen project can still have something running: standard errors, or a simple, well-defined ablation we agreed on in advance. It cannot have a new idea that changes the story. Writing needs a stable target; you cannot describe a result that is still deciding what it is. Once the experiments are done, the words and the formulas get the full attention they deserve, and the paper gets better fast.

One week of writing is the minimum we will need. Less leads to bad papers, simple as that.

Between the freeze and the deadline, at least one week of pure writing time; more whenever we can afford it, and never less. (Exceptions exist. They are exceptions, and they prove the rule rather than replace it.) This is also our deadline test. If a week of writing does not fit before the date, the date is wrong, and we want to know that early enough to do something about it. The deadline serves the work. Not the other way round.

Writing is the last review, and the hardest.

When you write the work up, problems surface: a control you missed, a claim that does not quite hold, an experiment you now wish you had run. This is normal, and it will happen. Sometimes the fix is small. Sometimes it means we cannot hold the deadline. That hurts. But it is good, not bad, because the writing caught the problem before a reviewer or a reader did. We publish when we are proud, not when the calendar says so.

No one carries a paper alone.

Reviewing a colleague's draft early is the work. Catching the gap between what the methods claim and what the code does is the work. Ask for time before you need it; give time before you are asked. And if you find yourself pushing in every direction on your own, that is not endurance to be admired, it is a gap in the group to be closed. We finish together, or we have not understood what together is for.