Those who are disagreeing with the author seem to not realize that he's just engaging in a bit of navel-gazing wordplay. Sort of like when people say "good programmers should be lazy". What they really mean is that good programmers should think ahead and craft their code with an eye minimizing future modifications.
Similarly, I think the author is simply saying that well written, easy to read, easy to understand code shouldn't have to be re-read multiple times by the same person. Which is good. The inverse would be that difficult to understand code would have to be read, re-read and studied deeply to actually grok. And thus read a lot. Which is bad.
I think the critics (myself included) perfectly understood that point.
> What they really mean is that good programmers should think ahead and craft their code with an eye minimizing future modifications.
The critique is exactly that this can not happen in real world projects because you can only speculate what requirements for the code base is down the road.
To counter this I usually apply two princinples:
1. Occam's razor - implement the simplest solution
2. Write code that is readable and understandable, so it is easier to change the code with the requirements.
The last being completely opposite to what the author of the article thinks.
The worst thing I can think of is somebody needlessly DRYing up a code base prematurely - this is in my opinion a junior behavior.
Basically he's saying that if the API is great you rarely need to read the implementation. To which: sure, in some blessed cases where the API was great to start with and nothing changed so you don't need to change the API or the implementation.
Similarly, I think the author is simply saying that well written, easy to read, easy to understand code shouldn't have to be re-read multiple times by the same person. Which is good. The inverse would be that difficult to understand code would have to be read, re-read and studied deeply to actually grok. And thus read a lot. Which is bad.