If your first quantum program ran perfectly on the first attempt, that is not a victory, it is a warning sign. Ideal simulators make almost anything look correct, and the mistakes that actually cost you time stay invisible until you move to real hardware or hand your code to a colleague. In practice, the same handful of errors shows up again and again in beginner code. Catching them early saves days of confused debugging.

Here are the seven worth fixing first, roughly in the order you will run into them.

1. Mixing up qubit ordering

You prepare a two-qubit circuit, expect 01, and get 10. Nothing is broken; you are reading a bitstring in the wrong direction. Frameworks disagree on endianness. Broadly speaking, Qiskit's bitstrings put qubit 0 on the right, while Cirq follows the qubit order you passed into the circuit. Tutorials rarely spell this out, and copy-pasted code carries the original author's assumption with it.

The fix takes five minutes. Build the smallest possible circuit: apply an X to qubit 0, measure everything, print the result. Run it once per framework, once per backend, and once when you start mapping logical qubits onto physical ones. That single experiment tells you the convention for your whole stack. Then label your registers explicitly instead of trusting positional arguments, and read your result objects rather than assuming a shape.

2. Placing measurements by habit

Measurement is not free observation. It is a physical operation that collapses the state, and on real hardware it is one of the slower and noisier things you can ask a device to do. Beginners tend to measure in three bad places: in the middle of a circuit while still applying gates to the same qubit, inside a loop where a single terminal measurement would do, and before the last layer of entangling gates has finished.

Mid-circuit measurement is legitimate, and it is essential for dynamic circuits with classical feedforward. But it needs support from the device and the compiler, and it changes your state irreversibly. You cannot measure a qubit, keep using it for phase-sensitive work, and expect the same answer as before. If you need information mid-circuit, be explicit about the collapse and about which conditional branches you are relying on. Otherwise, keep measurements at the end.

3. Assuming the simulator's noise looks like real noise

There are two versions of this error. The first is trusting a noiseless statevector run to predict hardware behaviour. The second is subtler: running a noisy simulator with a calibration snapshot from months ago and treating it as a live description of the device.

Real noise drifts. Gate errors differ from qubit to qubit. Crosstalk depends on which operations you schedule in parallel. A few assumptions to check before you trust any noise model:

• All two-qubit gates share the same error rate. They rarely do, and the best pair on a device may be nowhere near your chosen layout.
• Readout error is symmetric. Reading a 1 as a 0 and a 0 as a 1 can have noticeably different rates.
• Idle qubits hold their state indefinitely. They decohere while they wait.
• Error rates are stable across a queue window. Run a small baseline circuit alongside your experiment to see today's numbers.

4. Testing only on simulators

Statevector simulation has no connectivity limits, no gate durations, and no queue. Code written against that model can quietly assume all-to-all coupling and infinite coherence, which is a different machine from the one you will eventually submit to. Simulation cost also grows exponentially, so the habit tends to cap your experiments at sizes where the interesting behaviour has not appeared yet.

Move to hardware earlier than feels comfortable, with a deliberately tiny circuit. A four-qubit smoke test that runs weekly tells you more about your pipeline than another week of perfect simulator plots. Keep the noisy simulator in the loop as a middle step, but do not let it become the only environment your code has ever seen.

5. Ignoring what transpilation does to your circuit

The circuit you write is not the circuit that runs. If your entangling gates touch qubits that are not physically connected, the compiler inserts SWAP gates to route the information, and each SWAP expands into several two-qubit gates. Depth climbs, fidelity drops, and the algorithm you designed no longer fits in the coherence budget.

Get in the habit of reporting depth and two-qubit gate count next to every result. Try more than one optimization level. Pick a layout that keeps your most-used pairs adjacent, and choose a device whose topology matches your circuit's interaction graph instead of accepting whatever the default is. If your method's advantage depends on shallow circuits, routing can erase that advantage entirely, and you would never see it in the statevector simulator.

6. Trusting a single run of a small number of shots

Probabilities estimated from shots carry statistical uncertainty of roughly 1 divided by the square root of the number of shots. With a hundred shots, that is on the order of ten percentage points. Reporting a difference between 0.52 and 0.50 from that data is reporting noise.

Run the job again. Change the seed where the backend allows it. Report intervals rather than single numbers, and be careful with post-selection: discarding shots because they look wrong changes your denominator and biases the estimate in your favour without you noticing. If your conclusion flips when you add shots, it was never a conclusion.

7. Building circuits you cannot check by hand

A subroutine with a wrong phase, a missing inverse, or a control on the wrong qubit will still produce plausible-looking counts. Without an independent expectation, you have no way to tell a genuine result from a bug that happens to be symmetric.

For small circuits, compute the expected state or outcome distribution yourself, even roughly. Compare against a reference implementation, and check building blocks in isolation with a unitary or statevector comparison before you assemble them into something larger. A two-qubit gate test that fails in three seconds is worth more than a two-hour hardware run that produces a chart nobody can interpret.

A pre-run checklist

Before you spend queue time, walk through this list. It takes two minutes and catches most of the above.

1. Verify qubit ordering with a single-X circuit on this exact backend.
2. Confirm every measurement is intentional and, ideally, terminal.
3. Print depth and two-qubit gate count after transpilation.
4. Run a small baseline circuit to sample today's error rates.
5. Estimate how many shots you need before you claim a difference.
6. Check each block against an independent expectation.
7. Run a tiny version on hardware before scaling up.

None of this requires advanced theory. It requires treating the compiler, the device, and the statistics as real parts of the program rather than details to sort out later. Do that, and the debugging conversations get much shorter.

Photo: geralt / Pixabay