Why The Same Steps Give Different Answers Each Run

When behaviour changes between runs, something outside the instructions is participating in the outcome.

Nothing unnerves a beginner quite like a program that works, then does not, then works again, with nothing apparently touched. It feels like the ground has become unreliable. It has not. Identical instructions produce identical results given identical circumstances, so if the results differ, the circumstances differed. The task is to find what is participating that you have not accounted for: leftover values from a previous run, information arriving in a different order, something being asked for before it is ready, or a deliberate element of chance that you introduced and forgot.

Timing is a particularly slippery source, because it produces failures that appear rarely and vanish under inspection. Two pieces of work that both touch the same value, without an agreed order between them, will usually happen to interleave harmlessly and will occasionally not. Watching more carefully often changes the timing enough to hide the problem, which is maddening and also a strong clue about what kind of problem you have.

Treat inconsistency as a category of evidence rather than an insult. The moment you accept that some hidden input is varying, the investigation becomes ordinary. List everything the behaviour could depend on beyond the instructions themselves. Fix each one deliberately, so nothing is left to circumstance, and see whether the behaviour settles. A problem you can make happen on demand is nearly solved. Most of the effort in these cases goes into making it reliable, not into fixing it once it is.