The Difference Between Reading Code and Writing Code

It's easy to feel like a fluent developer while barely writing any code yourself. Reviewing pull requests, reading a teammate's implementation, tracing through a stack trace to find where a bug actually lives — all of that is real, valuable work, and it genuinely does keep one skill sharp. It just isn't the same skill as producing code from nothing.

Reading code and writing code share a lot of surface area, which is exactly what makes it easy to conflate them. You can be excellent at spotting what's wrong with someone else's loop and still freeze, a little, when asked to write one yourself from a blank editor. That gap doesn't show up anywhere in day-to-day work — it only shows up the moment something forces you to produce instead of evaluate.

Why comprehension stays strong while production quietly fades

Reading code gets constant, unavoidable practice: every pull request, every bug report, every unfamiliar file you open. Writing code from scratch, on the other hand, is increasingly something an assistant does the first draft of, with you reviewing and adjusting rather than producing it yourself. One skill gets exercised by default; the other only gets exercised on purpose — and a skill that's only exercised on purpose is exactly the kind that erodes without anyone noticing.

The interview room is where the gap becomes visible

This is precisely why a strong code reviewer can still have a rough time in a live coding interview. Reading and critiquing a finished solution draws on pattern recognition built over years; writing one from an empty file, under time pressure, with no assistant filling in the syntax, draws on a completely different kind of recall — and it's the one that's had far less recent exercise for a lot of experienced developers right now.

What each skill actually requires

• Reading: recognizing intent. Following someone else's logic, spotting the actual bug in a diff, and understanding why a given approach was chosen — all pattern-matching against code you didn't have to produce yourself.
• Writing: recalling exact syntax. Producing correct loop structure, method names, and control flow from memory, with nothing suggesting the next line — a much more literal kind of recall than reading requires.
• Writing: holding the whole plan in your head. Structuring a solution from scratch means deciding the shape of the answer before a single line exists, not reacting to a shape someone, or something, else already committed to.
• Both: knowing when you're actually stuck. It's easy to mistake "I'd recognize the right answer" for "I could produce the right answer" — the two only ever get told apart by actually trying to write it.

Exercising the half that goes quiet

None of this is an argument against code review, or against reading other people's work — both stay genuinely valuable and worth doing. It's an argument for treating writing-from-scratch as its own skill that needs its own deliberate exercise, rather than assuming it's covered by everything else a normal engineering job already involves.

That's the specific gap SoloScript's exercises are built to close — short drills that force you to actually produce a solution, not just recognize a correct one, in practice.