Lena’s first month of running circuits on cloud quantum hardware went the way it goes for many newcomers. She queued jobs, collected histograms, tweaked a few gates, queued more jobs, and slowly lost track of which result came from which version of the circuit. When her supervisor asked why Thursday’s fidelity looked so much better than Monday’s, she had a dozen notebook cells, three exported result files and no clear answer. That evening she started a quantum experiment log: a few dated lines after every session about what she ran, what she saw and what she would try next. Along the way she ran into several beliefs about logging that turned out to be wrong. Here are six of them.

Myth 1: “The job results already record everything”

Cloud quantum platforms return a lot of metadata with each job: the backend, the number of shots, timestamps, sometimes calibration snapshots. Lena assumed that was enough. It was not. The metadata told her what ran, but not why she had changed the circuit, which variant she considered the baseline, or that she had swapped the qubit mapping because two qubits looked noisy that morning.

Reality: machine records capture the execution; a quantum experiment log captures the reasoning. When she later compared runs, the one-line note “moved to qubits 2 and 3 because 0–1 readout error looked high” explained more than any JSON file.

Myth 2: “Quantum results are noisy anyway, so notes won’t help”

This one sounds plausible. Results on current hardware are probabilistic and affected by noise, so why record small differences that might be random? Lena’s experience was the opposite. Precisely because results vary, context matters more. Was the drop in success probability due to her change, a calibration shift, or simply a different time of day on a busy device? Without dated notes, she could not tell signal from noise even in hindsight.

Reality: noise makes a log more valuable, not less. Writing down conditions alongside each run — device, approximate time, circuit depth, any mitigation applied — is what lets you separate genuine improvements from luck.

Myth 3: “A notebook file is the same as a log”

Lena worked in interactive notebooks, and she thought the notebook itself was her record. But notebooks get edited in place. Cells are rerun out of order, outputs are overwritten, and the version she had on Tuesday no longer existed by Friday. The notebook showed where she ended up, not how she got there.

Reality: a notebook is a workspace; a log is a history. She kept both. At the end of each session she wrote a short, dated entry in a separate file, with the commit or file version for the notebook and a sentence about what changed. When she studied algorithms like the quantum Fourier transform and its role inside larger algorithms, the log let her trace exactly how her implementation evolved from a textbook sketch to something that ran on hardware.

Myth 4: “Simulator work doesn’t need logging”

Early on, Lena only logged hardware runs. Simulator runs felt like scratch work. Then she spent an afternoon chasing a discrepancy between hardware and simulation, only to realise she had changed the simulator’s noise model a week earlier and forgotten. The “scratch” decision had quietly shaped every comparison since.

Reality: simulator settings are part of the experiment. A single line — “switched simulator to noise model based on yesterday’s calibration” — would have saved her hours. She now logs simulator configuration changes as carefully as hardware runs.

Myth 5: “Logging slows research down”

Lena worried that writing after each session would eat into precious lab time. In practice, entries took two or three minutes. What they saved was much larger: the warm-up time at the start of each session, the repeated experiments she had already tried and forgotten, and the confused hour before supervisor meetings trying to reconstruct the week.

A typical entry looked like this: “Nov 4. QAOA, 4-node max-cut. Depth 2, 4000 shots on hardware. Approximation ratio lower than simulator. Suspect readout error; next: apply readout mitigation and compare.” If you are curious about that family of methods, this site explains how quantum algorithms approach hard optimisation problems; the log is what turned her reading into a series of experiments she could actually learn from.

Reality: logging is faster than rediscovery. The time cost is small and front-loaded; the time saved accumulates.

Myth 6: “Logs are only useful to the person who writes them”

Lena expected the log to be a private memory aid. Then her lab mate, Tomás, took over part of her project while she spent a month on a different collaboration. Instead of a long meeting, she shared her log. Within a day he knew which circuit variants had failed, which devices had given unstable results that month, and which mitigation technique had helped. He said the failed variants saved him the most time.

Reality: a log is the easiest handover document there is. It is dated, honest about failures and already written by the time anyone needs it. In fast-moving fields where people rotate between projects, that matters as much as the science.

What Lena’s log taught her

After a few months, rereading the log revealed patterns she had not noticed in the moment. Certain circuit structures were consistently fragile on hardware. Some mitigation approaches helped only at shallow depths. Her best results clustered around specific choices she had made almost by instinct. Those patterns became the basis of a short internal report, and later a section of her thesis.

She also discovered that working logs are common in neighbouring fields. Researchers exploring where quantum methods could reshape machine learning often come from ML backgrounds, where the habit is well established. One colleague pointed her to AI Universe, where alongside posts about deep learning and data science there is a Stories area of everyday working logs kept by people in the field. Reading them, she said, made her own entries feel less like homework and more like part of doing research properly.

Starting your own quantum experiment log

• Date every entry and note the device or simulator used.
• Record what you changed and why, in one or two sentences.
• Note conditions such as shots, depth, qubit mapping and mitigation.
• Write down surprises and failures, not just successes.
• Finish with a next step so the following session starts with a plan.
• Link to the code version or notebook snapshot that produced the result.

Quantum computing is a field where memory is especially unreliable: the experiments are subtle, results are probabilistic and the tools change quickly. A few honest, dated lines after each session are a small investment that keeps your learning cumulative rather than circular.