Simulating the Two-Heads-in-a-Row Puzzle in 20 Lines of Python

Astra Quant — Fri, 06 Nov 2026 11:07:27 +0000

You flip a fair coin until you get two heads in a row. How many flips does it take, on average?

Most people say 4. It feels right: two flips for HH would be 4 if you somehow "double" a 50/50 wait. The real answer is 6. That gap between gut and math is why this puzzle is a favorite for learning expected value with states.

Below is a tiny Monte Carlo simulation that estimates the answer, then a short explanation of why six is exact.

The simulation

import random

def flips_until_two_heads():
    streak = 0
    n = 0
    while streak < 2:
        n += 1
        if random.random() < 0.5:
            streak += 1
        else:
            streak = 0
    return n

TRIALS = 100_000
total = sum(flips_until_two_heads() for _ in range(TRIALS))
print(total / TRIALS)

Run it a few times. You should see something like 5.99 or 6.01 — close enough to 6 that the pattern is hard to miss. Increase TRIALS if you want a tighter estimate; the math below shows what the simulation is converging to.

Why the answer is 6

Track only what matters: how many heads you currently have in a row.

State 0: no streak (start here, or after any tails).
State 1: just got one head.
State 2: two heads in a row — done.

Let E₀, E₁, and E₂ be the expected remaining flips from each state. E₂ = 0. From state 0 you always flip once: heads → state 1, tails → stay in 0. From state 1: heads → done, tails → back to 0.

So:

E₀ = 1 + 0.5·E₁ + 0.5·E₀
E₁ = 1 + 0.5·0 + 0.5·E₀

Solve those and you get E₀ = 6. You start in state 0, so the expected number of flips is 6.

The intuition that fails is treating "two heads" like "two independent waits of 2." Streaks reset. One tails throws you all the way back, which is why the wait is longer than 4.

A tiny takeaway

States beat gut estimates for streak problems. Once you name the states, the equations are almost mechanical — and the simulation is a friendly sanity check.

What's a probability puzzle where your first guess was way off? Drop it in the comments — I'd love to try simulating a few of yours.

A Tiny Probability Puzzle Every Developer Should Try

Astra Quant — Sun, 25 Oct 2026 11:10:01 +0000

Here's a puzzle I like to give developers, because it's short, slightly uncomfortable, and teaches something you'll use for the rest of your career.

The puzzle: Over the next month, write down 20 predictions about your work. Each one gets a probability. "70% this PR merges by Friday." "90% the deploy goes out without a rollback." "40% the flaky test fails again today." At the end of the month, check which happened.

Now the question: when you said 90%, did 90% of those things happen?

If you've never done this, I'll make a forecast of my own: you're overconfident. Most people are. Developers are especially prone, because we estimate things constantly (story points, timelines, "this'll take five minutes") and rarely look back at the receipts.

What calibration actually means

Being calibrated means your confidence matches your hit rate. If you're perfectly calibrated, then across everything you labelled "70%," about 70% came true.

Notice that calibration is not the same as accuracy. Someone who says "50%" about everything is perfectly calibrated on a coin flip and completely useless. What we want is to be calibrated and decisive: confident when we should be, uncertain when we should be.

Let's simulate it

Before you trust your own data, it helps to see what calibration looks like in a controlled world. The script below simulates two forecasters:

Honest Hannah, whose stated probability is the true probability.
Overconfident Omar, who sees the same truth but pushes his estimate toward the extremes.

Then we bucket the forecasts and compare stated confidence to observed frequency, and compute a Brier score (lower is better).

import random

random.seed(42)

def overconfident(p, strength=1.8):
    """Push a probability away from 0.5 toward 0 or 1."""
    odds = (p / (1 - p)) ** strength
    return odds / (1 + odds)

def simulate(n=10_000):
    hannah, omar = [], []
    for _ in range(n):
        true_p = random.uniform(0.05, 0.95)
        outcome = 1 if random.random() < true_p else 0
        hannah.append((true_p, outcome))
        omar.append((overconfident(true_p), outcome))
    return hannah, omar

def brier(forecasts):
    return sum((p - o) ** 2 for p, o in forecasts) / len(forecasts)

def calibration_table(forecasts, bins=10):
    buckets = [[] for _ in range(bins)]
    for p, o in forecasts:
        idx = min(int(p * bins), bins - 1)
        buckets[idx].append((p, o))
    rows = []
    for b in buckets:
        if b:
            stated = sum(p for p, _ in b) / len(b)
            observed = sum(o for _, o in b) / len(b)
            rows.append((stated, observed, len(b)))
    return rows

hannah, omar = simulate()

for name, data in [("Hannah", hannah), ("Omar", omar)]:
    print(f"\n{name}  Brier score: {brier(data):.4f}")
    print(" stated  observed    n")
    for stated, observed, n in calibration_table(data):
        print(f"  {stated:5.2f}    {observed:5.2f}  {n:5d}")

Run it and look at Omar's table. In his top bucket he says something like 0.97, but those events happen closer to 0.9. In his bottom bucket he says 0.03, but they happen more like 0.1. His Brier score is worse than Hannah's, even though he had exactly the same information. The only difference is how he translated belief into numbers.

That's the uncomfortable lesson: you can lose accuracy without knowing less. You just have to be a little too sure.

Try it on yourself

You don't need a fancy setup. A text file works:

2026-11-02 | 0.80 | PR #412 merged by Friday | 1
2026-11-02 | 0.60 | No pager alerts this weekend | 0

After 20 to 30 entries, feed the probabilities and outcomes into calibration_table and brier. With small samples the buckets will be noisy, so use 3 to 5 bins instead of 10.

What people usually discover

The 90% bucket is a liar. Things you were "basically certain" about fail surprisingly often.
Estimates cluster. Many people only ever use 50%, 80%, and 95%. Forcing yourself to pick 65% or 72% sharpens thinking.
Base rates beat vibes. "How often has a deploy like this rolled back before?" is a better starting point than "it feels fine."

Why this matters for developers

Estimation is a huge part of our job, and it's rarely trained. Calibration gives you a feedback loop: not "was I right?" but "was my confidence right?" That's a much kinder and more useful question. It turns estimates from a source of anxiety into a skill you can measure and improve.

So: 20 predictions, one month, one small script. Post your Brier score in the comments if you're brave. I'll go first next month.

DEV Community: Astra Quant