How much you suck as an engineer = 1/(sum(len(n) for n in Nv)/len(Nv))

Good points. Some rebuttals:

First, in the context of this argument, I'm talking about work in high level languages like Python, JS, fairly expressive C++, etc. If we were coding in assembler -- LEA, LDR, JNZ.. -- I'd definitely want a ton of low level comments!

When I say wasting space, it's not about disk space, or shrinking your screen size, or even formatting. It's more about what you can see all at once.

Think back to a recent time when you had a tough to fix bug. Like something really not trivial that you beat yourself up about for a while.

I bet it involved you working through various levels of libraries, opening them side by side or paging back and forth, trying to figure out what went wrong in the logic.

It probably wasn't cuz you misunderstood what a variable did. We have great ways to document that, like the function header.

Now imagine that process if it's all on the same screen. If everything feels "tangible" to you, because each level of logic (to some reasonable point) is visible, accessible.

When I encounter a code base with hundreds of source files in various folders and some flimsy abstraction tying it all together, such that I can't see a clear delineation between parts, I go nuts!

Here's a very practical example. Imagine you have some library that wraps a remote API. Something important, like Payments. The hard part there is understanding failures (does it retry?), edge cases (whats diff when i run a test CC#?), stored state (can I resume this from a different part of the code?).. those things are mighty hard to glean even from good statement-level comments, even if I could take the time to read all 3,000 lines of code.

We need higher level great docs.

I'd love to code in English or something like it, but looking at the code on my screen right now, those would be some really complex sentence structures. :)

Excess whitespace is extremely harmful, because it reduces, in exact proportion, the amount that can be seen, at once, of the code that actually does things. Same applies to prolix commenting. The code that does things is what people working on it need to see. A comment that explains why a thing is done might be consulted when purpose is unclear or not obvious. That is why a good coding editor grays out comment text.

Whitespace deployed very judiciously directs attention where it is needed without need for distracting verbiage.

Far more scarce than any other resource is attention. Anything that steals attention away from where it is needed most is actively harmful, creating bugs and misdesign, and knocking people out of productive flow.

IMHO, comments should never describe what the code does. We're engineers, we can all read code and see what it does (or refer to the Javadoc). Comments should be used to describe WHY the author is doing something non-obvious in the code.