It seems to be an iron-clad irony of writing that the number of proof reads required to find all errors in your writing is:
PR = N + 1
Where ‘N’ is the actual number performed. This rule appears to apply regardless of the actual value of ‘N’.
As I post these blog articles, I run into this law time and time again. The math is unassailable and inescapable. The moment I publish an article, even after carefully reading and re-reading it, when I later read that article on the blog I immediately spot an error.
So back into Edit mode I go to fix the offending bit.
And no matter how often I re-re-read the fixed version, guess what happens the next time I happen read it: Writing errors appear to be like mold and fungus, springing to life all on their own.
And as a programmer I know that the same law applies to software bugs. No matter how many tests, no matter how many checks, at least one always lurks waiting for the unsuspecting user.
All seriousness aside, part of this–at least for me–seems to have to do with viewing words on a monitor as opposed to the printed page.
I noticed many years ago that I could spend many unsuccessful hours trying to find an elusive coding error. But no matter how many times I went over the code on the monitor, I just couldn’t spot it.
Finally I would surrender and decide to go home.
I’d print the code, and time after time, the first time through the printed copy the bug would practically leap off the page and grab me by the throat.
Sometimes I’d spot the bug while just leafing through the printed pages while walking back to my desk.
So printing my code became a standard technique, but it was a frustrating technique in that those printed pages became obsolete almost immediately.
I have several cases (cases, not reams) of “scratch paper” in my closet. A lifetime supply!
Eventually three things happened that ended this habit, and I haven’t printed a line of source code in many years.
Firstly, the quality of monitors and fonts grew to nearly match the printed page. All my editors feature paper-like white backgrounds, black “ink” and high-resolution fonts.
(This, however, does not explain the weird mathematics of blog article proofing.)
Secondly, (I believe) I grew better at reading computer monitors. The change in the ability to spot bugs slightly pre-dates the improvement in monitors, which seems to indicate some other reason for the change than just the monitors.
(This, also, does not really explain the blog article proofing problem.)
Finally, I became a much better programmer over the years. The occasions of those mysterious, elusive, hard-to-find bugs are rare and far between.
And when they do occur, my tools and techniques make short work of them. (This is almost a disappointment; debugging has become a favorite activity.)
This last point may explain the blog proofing problem.
I just need to build my skills!