Small questions evaporate if you don't catch them.
"Why is this faster?" "Does this actually work?" "What happens if I try it this way?" — these thoughts show up constantly while coding and vanish just as fast. Most never get tested, because setting up a whole project for a two-minute question feels like too much friction.
This repository removes that friction. Each idea gets a folder, a script or notebook, and a short write-up of what was tested and learned. The point isn't polish — it's that the question got answered instead of forgotten.
If something here looks dumb, that's probably the point.
What keeps a playground usable.
One idea, one isolated folder.
No shared code between experiments. Isolation keeps each one simple, focused, and safe to break without touching anything else.
Always write down what you learned.
Every folder carries an
explained.md: what was tested, why, and what it showed. The note is the actual deliverable.Measure, don't assume.
Performance claims get a
timeitnumber attached. "Feels faster" isn't an answer here.
Deliberately, aggressively simple.
There's no framework and no build. A typical project is a single entry file plus a note, runnable directly.
The isolation is a feature, not laziness. Because no experiment depends on another, any folder can be deleted, rewritten, or ignored without consequence — which is exactly what makes it safe to try the reckless idea.
Public experiments build intuition faster.
The reason this repo exists is straightforward: experimenting in the open is how you learn faster, remember why things work, and stop being afraid of "wrong" code. A benchmark you actually ran sticks in a way a blog post you skimmed never does.
It's the counterweight to the polished projects — proof that the same person who ships clean pipelines also pokes at small questions for their own sake. The habit is the product.
Not a library. Not a tutorial. A sandbox.
It's explicitly none of the things people expect from a public repo — not a framework, not best practices, not reusable. Framing it that way up front frees every experiment from the pressure to be good, which is the only condition under which the reckless-but-illuminating ones actually get written.
Three ways to grow it.
An index of findings.
A top-level table linking each folder to its one-line result would make the accumulated learning browsable at a glance.
Reproducible benchmark harness.
A tiny shared timing helper (kept optional) would make speed claims comparable across experiments and machines.
Cross-language probes.
Widening beyond Python into the same question in JS or C would turn single benchmarks into genuinely interesting comparisons.