This post seems to take the attitude that "documentation will always suck, so just go right to the source". I think this attitude can impede software projects

This post seems to take the attitude that "documentation will always suck, so just go right to the source". I think this attitude can impede software projects with changing code (that is, all of them). The problem is that the source can only tell you what a program does, not what it is supposed to do. If you don't know what it is supposed to do, it can be difficult for consumers of the code to know whether some behavior is is intended or a side-effect of the current implementation. Likewise, code maintainers can be prevented from changing the implementation when they don't know if consumers are relying on undocumented behavior. It's more difficult to file bugs against undocumented code; how do you know it's a bug if you don't know what the code is supposed to do? In brief, good documentation and good code are a virtuous cycle. Reading the source is often necessary but it should be viewed as a failure of documentation.