I spent three weeks reading the React docs on reconciliation, very politely, and came out with a mental model that felt like a map of a city I'd never walked.
So I stopped being polite. I wrote the worst component I could think of. It mutated its own props, set state during render, hid a useState inside an if, used array indexes as keys in a list that kept reordering, and had a useEffect whose dependency array guaranteed an infinite loop.
React complained about every one of those, and each complaint taught me something the docs had only described. Mutating props, I could see the exact render where React failed to notice the change. Breaking the hook order, the stack trace showed how React pairs state with a component by call position, which is the whole reason the rules of hooks exist.
The red text stopped feeling like a telling-off. It was a guided tour, just a rude one.
How I break things now
Random breakage is noise, so I keep it boring. Start from code that works. Break one thing at a time, or you won't know which one did the damage. Write down what happened. Then fix it by hand instead of reaching for git checkout, because the fix is where the understanding lands.
It works well beyond React. CSS grid areas clicked for me after I fed the browser overlapping rows and invalid line names and watched it sort out the mess. JWT verification became real the day I edited a payload in an intercepting proxy and the backend refused the signature. A new API gets a deliberately broken JSON body from me on day one: does it answer with a clear 400, or fall over with a 500?
That one request usually tells me more about a codebase than its README.
Somewhere safe, please
All of this happens on my own machine, in environments I can throw away. I've seen what happens when someone experiments on a production database instead. Nobody learns much, and everyone gets a very long meeting.
So next time an abstraction refuses to make sense, close the docs, write the worst version you can, and watch it break.