Why Typing It Out Still Matters
You read a solution, it makes complete sense, and you nod along thinking "yeah, I could have written that." Then a week later, faced with a blank editor and the same problem, nothing comes. Not because you didn't understand it the first time — you did — but because understanding and producing turn out to be two different skills, and only one of them gets exercised by reading.
This gap matters more now than it used to, because reading and verifying code (an AI's suggestion, a Stack Overflow answer, a teammate's PR) has quietly become the dominant way most people spend their coding time, while the actual production side gets less practice than it used to by default.
Recognizing a solution isn't the same as producing one
Psychologists draw a real distinction between recognition memory and recall memory: picking the right answer out of a lineup is a much easier task than generating that same answer from nothing. Reading code is a recognition task — does this look right, does this make sense. Writing code from a blank file is a recall task. You can be excellent at the first and rusty at the second without ever noticing, because most days only ask you for the first.
What actually gets reinforced by typing
Typing code out forces retrieval: your fingers and your memory have to produce the exact syntax, method name, and structure instead of just confirming that someone else's version looks correct. That act of generating something from memory, rather than verifying it, is consistently what strengthens long-term recall — a plain, well-documented effect in how people learn skills, not just a coding-specific quirk.
Where this shows up in practice
- Copy-pasting reads as understanding, until you're asked to modify it. Following the logic of code you didn't write is a real skill, but it's not the same one as being able to write something structurally similar yourself.
- A concept feels solid right after you see it explained, then evaporates by next week. Without any retrieval in between, that's the expected outcome, not a sign you weren't paying attention.
- You can explain what code does in the abstract but stall on the first line yourself. That stall is the recall gap showing up directly, not a comprehension problem.
- Debugging someone else's code feels fine, writing the same pattern from scratch doesn't. Those are genuinely different tasks, and being strong at one doesn't guarantee the other.
This isn't nostalgia for typing everything by hand
None of this is an argument against using real tools for real work — write production code however you actually work best. The point is narrower: a practice session built entirely around reading and reviewing doesn't build the same muscle as one built around producing something from nothing, and if the second one matters to you, it needs its own dedicated time, not a hope that it happens as a side effect of the first.
That's specifically what SoloScript gives you a place to do: a prompt and a blank editor, not a solution to review, so the thing being exercised is production and recall, not recognition.
Free, no account needed. A few minutes a day is enough to feel the difference.
Start practicing