Hmm. I mostly agree with the author's statements like "documentation exists so that code can be easily used" and "it [the code] is the most honest account of wh

Hmm. I mostly agree with the author's statements like "documentation exists so that code can be easily used" and "it [the code] is the most honest account of what actually happens when you run the code." But introducing the triangle as a metaphor infers each member of the triangle is the same type of thing. The "WHAT" vertex is the code itself while the "HOW" and "WHY" verticies are natural language text. "HOW" and "WHY" are not easy to distinguish and seem to be used to mean "context outside the immediate function" and "programmer's intent." I think the triangle metaphor muddies the water a bit. But... I agree with most everything else the author says. Context is important and is not present in the code (usually.) The developer's intent is generally absent from the code and should be supplied somehow. I might even go further to explicitly mention documentation at the top of a function traditionally describes that function's context in the greater scope of the application or module or class while documentation inside the code body often describes the programmer's intention with respect to the function's implementation. (This is just an observation from code I think is well documented. Maybe there are counter-examples out there.) I have a bit of an architectural bent, so I might have talked about documentation and it's relation to interface/implementation and problem domain and solution domain. Which is to say, documentation should be clear about which domain you're documenting. Though I don't understand why the triangle is important, props to the original author for saying "no. code is not self documenting."