
Why It’s So Hard to Catch Your Own Typos - mikeleeorg
http://www.wired.com/2014/08/wuwt-typos/
======
kazinator
Why it's so hard to catch your own typos is that, being the amazing hacker
that you are, you're too cool for word processors with spell (and grammar)
checkers.

You've tried the command line spell checkers, but they all irksomely need to
be taught to ignore various tokens emanating from your markup language,
requiring you to drag a custom dictionary from account to account, system to
system, or else do it all over again.

Plus all spell checkers of all kinds choke on the technical language you use,
especially the acronyms and strange names: OSPF, ISDN, XML, Yacc, GCC, C++,
... All have to be painstakingly marked as valid, to be ignored (as long as
you're on the same computer with the same dictionary for the same spell
checking application).

Spell checking technical writing is a pain in the butt, and so sometimes it
doesn't get done.

------
tjradcliffe
While proofreading my novel (shameless plug: [http://www.amazon.com/Darwins-
Theorem-TJ-Radcliffe-ebook/dp/...](http://www.amazon.com/Darwins-Theorem-TJ-
Radcliffe-
ebook/dp/B00KBH5O8K/ref=sr_1_1?ie=UTF8&qid=1408040140&sr=8-1&keywords=darwin%27s+theorem))
I wrote a bit of Python to do the following:

1) break the original text file up into about 200 chunks of a few hundred
words each (always breaking on paragraph boundaries)

2) randomize the chunks

3) display each chunk with the font faded to almost invisible in a UI with a
"play" button that revealed one... word... at... a... time at an appropriate
reading pace (more on which below.)

I kept the original document open in an editor and made changes as I found
them (there was also a "pause" button, obviously!) The application kept track
of what chunks had already been proofed.

The randomization of chunks helped ensure I never got caught up in the story,
but the word-at-a-time reading was what really made it powerful. There were
still a few typos that crept past (there always are) but only two or three
have been found by readers.

The important thing is maximizing the degree of surprise you have at
discovering the next word. By tuning the reading rate appropriately I could
digest one word and have a few tens of milliseconds pause before the next one
showed up. This forced my attention to focus on what that word would be, and
brought stylistic problems to the fore as well as simple typos.

The process is not fast: there is a "speed of light" for proof-reading that
seems to be about 10 pages per hour (which is about what professional proof-
readers do) and I found I could only reasonably do a few hours per day, but
that was still only a couple of weeks to proof a 140,000 word novel.

This was also done after running the thing through various automated grammar
checkers (LanguageTool was the most useful:
[https://www.languagetool.org/](https://www.languagetool.org/)) which caught a
lot of more mundane errors.

I also had a decent editor and excellent feedback from first readers, which is
indispensable, but much more of the process can be automated than is generally
believed.

It is a truism that authors can't proof their own work, but with the right
attitude, reasonable tools and a modest amount of human backup it appears to
be practical.

~~~
daniel-levin
What did you do about proofreading bits of your manuscript that you couldn't
break apart into randomised, individual units? How did you make sure all your
punctuation and grammar was correct? For example, placing commas appropriately
in a sentence that only a human can understand. Surely this is also part of
the proofreading process?

~~~
tjradcliffe
I've been unclear. The chunks were randomized within the manuscript, but the
words within the chunks were left in order.

I randomized the chunk-ordering so I got dropped into a different part of the
story every few hundred words. This was sufficient to keep me from getting too
involved in the narrative, while allowing me to read complete sentences,
thereby being able to do the human-level stuff which you correctly point out
is so important.

------
js2
The last tip, seeing it in a different context definitely helps. Another thing
you can try is reading in reverse.

I find a context change helps when reviewing my code for bugs. I like to
publish my commits to a web-based code-review (I use Gerrit, but it doesn't
matter) even if I'm not adding a reviewer. Just looking at the diff in my
terminal doesn't seem to be enough of a context change (perhaps because I use
the same font/color scheme in my terminal and editor). Reading the diff in
Gerrit, I often catch something I'd missed. (Embarrassingly, I've more than
once caught a mistake after I've sent a patch to a mailing list.) I suppose I
could just use gitx for the context change.

------
TrainedMonkey
Same effect also works on "find differences" type of puzzles. Before you know
where they are pictures look the same and you need to focus your attention on
small part of the picture with few features. Once you know where differences
are they immediately jump out to you.

I suspect same cognitive information bias is part of the reason most people
believe themselves to be more intelligent than average.

------
throw_away
What I don't understand is how there can be so many simple spelling errors
(not the there/their kind, but rather the theer or hte kind) when it seems
like more or less every browser on every platform has a spell checker running.
Do people simply not see the red dotted lines? Or do they just not care?

~~~
itsybitsycoder
Most spell checkers are missing a ton of words, especially abbreviations/short
forms and technical terms. If you're writing a document where every line has a
red underline somewhere under it, and a quick glance shows you that all (or
nearly all) of those red underlines are wrong, ignoring them or disabling the
spell check can seem like the easier solution.

~~~
throw_away
Most cases I see aren't exactly filled with technical terms.

------
alok-g
Some observations:

1\. When proof-reading in print rather than on-screen, I catch three times
more typos. Not fully sure why.

2\. Giving gaps between writing and reading (even as small as 24 hours
especially if you spend time doing something else in the middle) helps quite a
bit, and not only with typos but also with the message itself.

------
RyanMcGreal
> Stafford says this evolved from the same mental mechanism that helped our
> ancestors’ brains make micro adjustments when they were throwing spears.

I'm not going to lie: knowing this makes my hours spent daily in front of a
keyboard feel just a little bit more badass.

------
visakanv
Summary: Because you aren't reading it "cold", you're reading it with
confirmation bias. You're reading it already knowing what the intent and
purpose is, so your brain glosses over the details and fills in the blanks.

------
rumblestrut
I enabled the ability for my Mac to speak text to me. I highlight several
paragraphs, use a keybinding to start it reading the text, and then follow
along while it reads the words. It's amazingly helpful.

