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.
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.
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.
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.
My favorite proofreading tip is to have the computer read writing back to me. The computer won't skim over sections. It will explicitly read every word. Your ears will pick up things that your eyes won’t. Grammar issues such as messed-up tenses become super-obvious when you do this. Obviously this doesn't always help with misspellings and it rarely helps with punctuation.
(FYI, on a Mac it is easy to setup a key command to read back selected text in System Preferences > Dictation & Speech > Text to Speech)
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.
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/) 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.
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?
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.
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?
There are probably a ton of variables but I bet some people don't even realize that the red line means anything. Let's say literally everyone did know it though.
Just having to right-click is enough to dissuade me. For people who have to look at a keyboard when they type, do they proofread what they typed?
Typing in anger/annoyance and getting your text out there faster is the biggest reason I can think of for my own typing.
I wonder also if being used to txt/chat abbreviations makes you ignore typos and move on more.
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.
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.
I find this interesting from a professional perspective -
A lot of companies employ manual input of information, my experience being in finance. Often a hand-written copy of a form in input to a system. Mistakes can involve financial loss. An often used 'solution' (often applied in finance) is to use a 'maker / checker' system where an individual (maker) inputs a field, and a checker checks what the maker input. [A checker is often ranked an order of corporate seniority over a maker.] For large value or sensitive transactions, a string of checkers may be applied (or suggested as remedies where accuracy is seen as a problem).
But... adding checkers rarely improves error rates. Checkers tend to trust Makers, and Makers tend to trust Checkers. More Checkers means more trust / less care - adding checkers can often make the chance of a mistake occurring higher.
A HNer may now suggest incentive structures, independent makers, technological solutions including drawing analogies with reCaptcha. I have done the same. Some operations companies do tried varied approaches, but many, including the largest of financial companies, do not for varying reasons. Not least as Operations departments of large multinationals have been squeezed by budget cuts of 10% per year for more than half a decade - some leads to outsourcing or offshoring, some moving the effort to the 'creator of cost' (i.e. changing the paper form to an input form).
I feel it would be an interesting challenge to sell something to enterprises seeking very high levels of accuracy (by which I mean, something in the order of 99.9% for non-standardised poorly scanned hand-written forms often including numbers, names and addresses).
The article is bull. This happens because your brain is predictive, not because there are magical "high-level" areas of the brain that don't pay attention to "lower" details. That's not how it works at all.
The brain transmits information between parts of it. A -> B -> C -> ..., with A, B, and C being sets of neurons (so one arrow is not just one connection, but somewhere between thousands and millions).
Whenever you're doing anything with your brain, you can simplify to this situation : every part of your brain is attempting to provide inputs to every other part. When multiple inputs are coming in, a selection is made (1) it wants correct input data (2) faster input data is better (3) when a "best" set of data is found, attention provided to any other signal will fall off exponentially.
This is normally very useful. Say you're jumping over a rock. You've done this before, so the part of the brain controlling your legs wants information ... "what's happening". And 2 parts of the brain will provide. One part will ultimately come from the sensors in your leg. But it's too late : by the time the sensors say you've hit the ground, it'll be ~0.05-0.2 seconds after you've hit the ground, potentially too late to compensate without falling over.
Fortunately, when you started the jump, a piece of your memory also said "hey, I recognize this, here's what's going to happen", and your leg control system will compare the values of the sensors for a while, agree with the memory, and start responding to memory input instead of sensor input.
Meaning your brain is responding to events it could not possibly have sensed. If you're looking for this behaviour, you'll see it everywhere. (In practice, of course, your brain also has a "physics simulator" that will provide input).
Assuming you've got good components providing all sorts of inputs, this mechanism is fantastic. You can look at something for a bit, have a simulation routine in your brain "synchronize" to it, look away to something else, synchronize to it, and then respond to both stimuli simultaneously despite your sensors (say, eyes) not actually capable of observing both stimuli.
Unfortunately, when you're re-reading a text you've written, the spell checker in your brain will switch to what you remembered writing down, and after a short while won't care what your eyes are actually reading any more. So unless the reading method calls attention (which it will only do in WTF cases), you'll miss any spelling errors.
Then you have the following 2 parts of your brain :
* a reading method that is providing outputs that contain the spell errors, but isn't actually connected to the spell checker any more, various other pieces of your mind might pay attention to it because they've got nothing better to do, and this might result in capturing attention, but probably won't.
* the memory, providing the correct input, connected to the spell checker
(in fact, shortly after that, the conscious part of the brain that is attempting to spell check will realize that the chance of getting an "error" signal from the spell checker is very small, and will "predict" that the spell checker will return an "OK" for the entire text and simply not listen for other signals anymore).
In short : do NOT count on humans (or animals, for that matter) to find small errors in repeating patterns. Write a short python function to do it for them.
I like to say that human minds respond "faster than light". In a sense, they do. You see this in martial arts championships (e.g. https://www.youtube.com/watch?v=a4lX0fKDTD8 ), where the outcome of an attack is determined before the first signals go out to the muscles, and these fighters are acutely aware of that. You see neither fighter is...
21 comments
[ 3.2 ms ] story [ 58.3 ms ] threadI 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.
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.
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.
(FYI, on a Mac it is easy to setup a key command to read back selected text in System Preferences > Dictation & Speech > Text to Speech)
I suspect same cognitive information bias is part of the reason most people believe themselves to be more intelligent than average.
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/) 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.
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.
Just having to right-click is enough to dissuade me. For people who have to look at a keyboard when they type, do they proofread what they typed?
Typing in anger/annoyance and getting your text out there faster is the biggest reason I can think of for my own typing.
I wonder also if being used to txt/chat abbreviations makes you ignore typos and move on more.
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.
A lot of companies employ manual input of information, my experience being in finance. Often a hand-written copy of a form in input to a system. Mistakes can involve financial loss. An often used 'solution' (often applied in finance) is to use a 'maker / checker' system where an individual (maker) inputs a field, and a checker checks what the maker input. [A checker is often ranked an order of corporate seniority over a maker.] For large value or sensitive transactions, a string of checkers may be applied (or suggested as remedies where accuracy is seen as a problem).
But... adding checkers rarely improves error rates. Checkers tend to trust Makers, and Makers tend to trust Checkers. More Checkers means more trust / less care - adding checkers can often make the chance of a mistake occurring higher.
A HNer may now suggest incentive structures, independent makers, technological solutions including drawing analogies with reCaptcha. I have done the same. Some operations companies do tried varied approaches, but many, including the largest of financial companies, do not for varying reasons. Not least as Operations departments of large multinationals have been squeezed by budget cuts of 10% per year for more than half a decade - some leads to outsourcing or offshoring, some moving the effort to the 'creator of cost' (i.e. changing the paper form to an input form).
I feel it would be an interesting challenge to sell something to enterprises seeking very high levels of accuracy (by which I mean, something in the order of 99.9% for non-standardised poorly scanned hand-written forms often including numbers, names and addresses).
The brain transmits information between parts of it. A -> B -> C -> ..., with A, B, and C being sets of neurons (so one arrow is not just one connection, but somewhere between thousands and millions).
Whenever you're doing anything with your brain, you can simplify to this situation : every part of your brain is attempting to provide inputs to every other part. When multiple inputs are coming in, a selection is made (1) it wants correct input data (2) faster input data is better (3) when a "best" set of data is found, attention provided to any other signal will fall off exponentially.
This is normally very useful. Say you're jumping over a rock. You've done this before, so the part of the brain controlling your legs wants information ... "what's happening". And 2 parts of the brain will provide. One part will ultimately come from the sensors in your leg. But it's too late : by the time the sensors say you've hit the ground, it'll be ~0.05-0.2 seconds after you've hit the ground, potentially too late to compensate without falling over.
Fortunately, when you started the jump, a piece of your memory also said "hey, I recognize this, here's what's going to happen", and your leg control system will compare the values of the sensors for a while, agree with the memory, and start responding to memory input instead of sensor input.
Meaning your brain is responding to events it could not possibly have sensed. If you're looking for this behaviour, you'll see it everywhere. (In practice, of course, your brain also has a "physics simulator" that will provide input).
Assuming you've got good components providing all sorts of inputs, this mechanism is fantastic. You can look at something for a bit, have a simulation routine in your brain "synchronize" to it, look away to something else, synchronize to it, and then respond to both stimuli simultaneously despite your sensors (say, eyes) not actually capable of observing both stimuli.
Unfortunately, when you're re-reading a text you've written, the spell checker in your brain will switch to what you remembered writing down, and after a short while won't care what your eyes are actually reading any more. So unless the reading method calls attention (which it will only do in WTF cases), you'll miss any spelling errors.
Then you have the following 2 parts of your brain :
* a reading method that is providing outputs that contain the spell errors, but isn't actually connected to the spell checker any more, various other pieces of your mind might pay attention to it because they've got nothing better to do, and this might result in capturing attention, but probably won't.
* the memory, providing the correct input, connected to the spell checker
(in fact, shortly after that, the conscious part of the brain that is attempting to spell check will realize that the chance of getting an "error" signal from the spell checker is very small, and will "predict" that the spell checker will return an "OK" for the entire text and simply not listen for other signals anymore).
In short : do NOT count on humans (or animals, for that matter) to find small errors in repeating patterns. Write a short python function to do it for them.
I like to say that human minds respond "faster than light". In a sense, they do. You see this in martial arts championships (e.g. https://www.youtube.com/watch?v=a4lX0fKDTD8 ), where the outcome of an attack is determined before the first signals go out to the muscles, and these fighters are acutely aware of that. You see neither fighter is...