Why We Built No-Repeat Memory

The request, and what it actually asks for

Teachers asked for it most, and the request was always some version of: I want everyone to get a turn, and the picker keeps choosing the same students.

That is not a complaint about bias. It is a complaint about coverage, and coverage is not something an independent draw provides — thirty independent draws from thirty names leave an expected eleven names untouched.

So the feature being asked for was not a better random picker. It was a different guarantee, and implementing it required giving something up.

What it costs

A no-repeat cycle draws from a shrinking pool. The first draw of thirty names is one in thirty; the fifteenth is one in sixteen; the thirtieth is a certainty.

That is a real change and it is not a small one. The odds are no longer equal, they are no longer even constant, and a student near the end of a cycle can work out that they are almost certain to be called.

We show the remaining count on screen rather than hiding it, because a tool that quietly changes the odds and describes itself as fair is doing the thing this whole site is supposed to be against.

Where we put it, and where we did not

It went into the cold-call picker, where coverage is the whole point. It went into truth-or-dare and the Scattergories letter picker, where repeating within a session is a game design failure rather than a fairness question.

It did not go into the raffle picker beyond removing drawn winners within a single multi-winner draw, because a raffle's core promise is equal odds and a memory that persisted across draws would break it silently for entrants who were not watching.

It did not go into the dinner decider, where a repeat is a legitimate suggestion, or the spinner wheel, where every spin should be an independent event because that is what a wheel means.

The limitation we could not remove

The memory lives in one browser on one device. It does not sync, it does not survive a private window, and it is lost if site data is cleared.

That is a consequence of the site having no accounts and no server, which is a deliberate constraint we are not going to relax — the whole proposition is that nothing you type goes anywhere. A synced no-repeat cycle would require an account and a server, and the trade is not worth it.

So the honest position is that this is a useful feature with a fragile store, and the tool says so on the page rather than letting a teacher discover it in November.

The boundary case

One thing the guarantee does not cover: a name drawn at the end of one cycle can be drawn at the start of the next. Two lessons running, from a tool advertised as not repeating.

That is a real gap and fixing it would mean constraining across cycle boundaries, which tightens the problem for no benefit — the guarantee people want is coverage within a cycle, not a global no-adjacent rule.

It is documented on the tool page, which is the alternative to fixing it and is the right call for something that affects roughly one student per cycle.

What we would need to build to do it properly

The honest version of this feature would sync. A teacher's cycle would follow them from the classroom machine to their laptop, survive a cleared cache, and be recoverable if a device died.

Doing that requires an account and a server, and the server would be holding class rosters — real names of real children, on infrastructure we would then be responsible for securing, for a feature that saves somebody re-pasting a list. That is a worse trade than it first appears, and it would also break the claim that nothing you type here goes anywhere, which is the site's actual proposition.

So the position is that this feature is deliberately less capable than it could be, for a reason we would rather state than quietly work around. If the local store is not good enough for your use, the correct answer is that this is the wrong tool rather than that we will build the server version later.

Frequently asked questions