Code Review as a Standard

No analysis code reaches a published result without a second person reading it; review catches what the author cannot see.

A second set of eyes, by default

Authors are blind to their own assumptions. Code review makes a second person read the analysis before it can produce a published number, and the reviewer's job is not to admire it but to try to find where it is wrong. This is standard practice in safety-critical software, and design-and-simulation fusion is exactly that kind of work.

What a reviewer checks

• Correctness: does the code implement the equations it claims to?
• Assumptions: are they stated, and are they appropriate for this case?
• Numerics: are tolerances, grids, and timesteps justified?
• Tests: are there unit and regression tests, and do they cover the risky paths?
• Provenance: does every constant have a source?

Review is about the work, not the person

A healthy review culture treats a found defect as a success, because it was caught before it reached a reader. We separate the code from the coder: the standard is impersonal, applied the same way to everyone, so that finding a mistake is normal and welcome rather than an accusation.

Code review is the internal analogue of peer review. It catches the ordinary errors early so that external reviewers and the public record are arguing about substance -- the physics and the gates -- rather than about a bug that should never have survived. Making review the default, applied impersonally to everyone and every result, is what keeps it from becoming a formality reserved for work that already looks doubtful -- the review that matters most is the one on the result everybody assumed was fine.