Lab as Code
A standard operating procedure in a Word document drifts. Different operators paste it into different files, add handwritten edits, and run slightly different versions without realizing it. By the time something goes wrong, it is hard to know which version ran.
A lab method written in Python has one authoritative version. It runs identically every time. It can be reviewed in a pull request and audited from a log file.
What this unlocks
- The script is the documentation: it shows exactly what happened, in what order, with what parameters
- Reproduce any run exactly: check out the commit, run the script with the same inputs
- Catch errors before touching samples: type checking and linting work on lab code just like any other Python script
- Integrate with anything: LIMS, databases, dashboards, Slack — because it is just Python
How it works
Consider a single protocol step. As a written SOP it reads:
# Manual SOP — Step 4
Set incubator to 37°C. Wait for temperature to stabilize. Confirm visually.
In Python:
await incubator.heating_controller.set_target_temperature(target_temperature=37)
await incubator.heating_controller.wait_for_temperature()
status = await incubator.heating_controller.get_status()
assert status.at_setpoint, f"Incubator not at setpoint: {status.current_temperature}°C"
The code version is unambiguous, executable, and verifiable. It does not depend on who is reading it or how carefully.
The compounding benefits
Version control
Every change to your method is a commit. git log tells you which version ran on Tuesday. git diff shows exactly what changed between the run that worked and the one that didn't. For regulated environments, this is an audit trail you did not have to build separately.
Reuse
Write a dilution helper once, import it everywhere. Utility functions for common operations — normalizing OD readings, reformatting plate maps, calculating volumes — accumulate into a shared library your whole team uses.
Testing
You can write unit tests against your method logic using mock connectors before touching any hardware. Catch logic errors — wrong well positions, off-by-one loops, incorrect volume calculations — before a sample is in the machine.
Auditability
Because you control the output format, every run can write a structured log that satisfies traceability requirements. The log is not a PDF export from proprietary software — it is an event stream and a JSON file you own and can query.
When to use this
A GUI might be faster for a genuine one-off. If you will run a method more than a few times, or if reproducibility matters, the code approach pays for itself quickly. The threshold is lower than it looks — a method you run twice already benefits from having a version you can diff and replay.
Next steps
- Operate: the four-stage structure of a lab method
- Error Handling: make your scripts resilient to device failures