It's precisely because I've learned to read and write so fast that I "skip over" the simple parts of sentences, making me oddly blind to certain categories of spelling errors!
Especially when I've gone over the same text over and over, I'll have memorised it to the point that I can skip entire sentences.
This is why you need someone else to step in and read the text for the "first time" and not skip anything.
The same applies to programmers and code review.
No it's not.
If an author produces gibberish and nobody checks, the published result is gibberish. And with print books uneditable in a run starting in the thousands.
If a programmer produces gibberish, it won't compile.
It also won't pass the unit test or acceptance tests, never mind QA or the alpha/beta testers.
But I think it's still the right analogy. You code review to make sure the code is comprehensible to other humans. You code review to make sure the tests (which are great automated protections) are protecting against the right things. And (most relevant to the analogy) getting those things wrong are not abnormalities that mean you're a bad programmer and we don't trust you, they're things that competent devs can get wrong all the time.
The equivalent in book writing would be that you are not allowed to write more than one page at a time, and someone must approve it before you start working on the next page.
If books were read by machines rather than humans, and were published incrementally, then it would make sense to ask someone to edit each iteration.
Incorrect. Bugs (“errata”) are regularly fixed in bugfix versions (“printings”) of books, whereas feature changes are regularly fixed in more major versions (“editions”). And that’s after the equivalent of a “1.0” release.
Books are also regularly iteratively released either to a closed group of reviewers or even the public (e.g., Manning MEAPs, PragProg Beta Books, etc.) prior to the equivalent of a “1.0” release.
But those fixes don't fix the already printed books.
For actual physical books (as opposed to ebooks, where making the complete new version available to purchasers for errata, but usually not new editions, is common), this is usually true for logistical reasons, though issuing errata sheets (usually online now, though the practice is older but notification and distribution was harder in the past) to keep existing users up-to-date is not uncommon.
That said, I do sometimes encounter individuals or cultures that seem to view code review more as a mechanism for catching abnormal/unexpected mistakes than as a normal part of the process of writing code.