Programmer Humor

Yeah, another way I've heard it phrased is comments are for explaining why you did things a certain way, not for explaining what it's doing.

If you're working with others, even simple code benefits from comments explaining what it's intended to do. Sure you can read code and get a good idea of what it seems to do, but you can't be sure that's what it was meant to do, or why it was meant to do that. Having a quick statement from the author enables you to work faster. And if you find a mismatch between the comment and the code, it's a smell that could mean a bug.

And for methods and functions it's particularly helpful to have a description at the top. Many IDEs will pop this up when you're using the method, so you can quickly confirm that it's appropriate for your needs and get your arguments in the right order.

I even comment code for myself because it will save me time when I return to the project months later.

No comments would be fine if you could trust that everyone writes code that does what it's intended to do and you can read code as quickly as you can read English. Maybe I'm a poor coder but I find neither of these is usually true.

That's like saying a book's synopsis shouldn't exist because you can just read the whole book. Sometimes comments can save you a lot of time and point you in the right direction.

Sounds very theoretical, my experience working on some 40 year old software full of business logic, where customer A got some feature but customer B needs it to work slightly different. Aka something approaching spaghetti.

Regarding old comments I have several times used ~15 year old comments by the original author, close to the actual code to piece together the use of that code, and if I can add my fix there.

In this setting You write comments for yourself, when you in two years need to fix a bug in the new code caused by your old code. And for the next developer that will look at your code decades after you left the company.

Sometimes you, against good practice, comment out a section, with a note why, because you know this will have to be re-enabled in a few months.

Report from the frontlines...

I have such a love-hate relationship with that video. On the whole, I think that video is bad and should be taken down. The creator is arguing against a very specific type of commenting but is harassing comments in all forms. It even addresses as such with a 20 second blurb 2/3 of the way into video distinguishing between "documentation comments" - but doesn't really provide any examples of what a good documentation comment is. Just a blurred mention of "something something Java Doc something something better code leads to better documentation" but doesn't elaborate why.
It's a very devious problem in that I don't feel like any particular claim in the video is wrong, but taken within the context of the average viewer, (I teach intro. comp. sci courses and students LOVE to send this video and similar articles to me for why they shouldn't have to comment their spaghettified monstrosities), and the inconsistent use of comments vs. code duplication vs. documentation, the video seems problematic if not half-baked.
In fairness, it is great advice for someone who has been working in the industry for 15 years and still applies for junior positions within the same company - but I can't imagine that was the target audience for this video. In my experience, anyone who has been programming on a large-ish project for more than 6 months can reach the same conclusions as this video.

This mindset is good, but unfortunately enforces bad programmers to leave their undocumented code in critical places where someone eventually has to figure out what the hell they were doing or refactor the whole damn thing because they got promoted to middle-management and can’t remember why they even wrote it.

Code comments are useful for browsing a script and understanding it at a glance. I shouldn't have to scroll up and down across 700 lines of code to figure out what's happening. It's especially useful with intellisense, since I can just hover over a function and get a tooltip showing the comment, explaining what it does. It also helps when using functions imported from other files, since it'll populate the comment showing me what parameters are needed and what each should be. Comments save time, and time is valuable.

One day you will inherit a code base so bad that you'll end up commenting old code just to make sense of it for yourself because nobody in the company has touched in a couple years and the last people that did no longer work there. It will be dangerously coupled, if you make the right change somewhere it will break everything else. It will be true spaghetti code where you spend 30 min just following a code path to figure out what and why an input into a function needs to be what it is to able to come out of another function in an exact format for anything to work.

Your so called comment standards and principals are fine if you are building something from the ground up, but the other 95% of the time, you do what you gotta do because your were blessed with a turd that is impossible to polish.

and if you need an unnecessarily complex code for performance sake?

Or you're stuck within the confines of a horrible legacy system which the business will not allow you the time to refactor/rewrite but still want your code to be somewhat readable.

But in general, I agree with your argument. When writing from scratch or improving reasonably well designed code, often documentation could be replaced by breaking it up into another function or naming variable better. It's a bit of a code smell for violating the SRP. And yet there are times that documentation is needed for the "why". Things are nuanced I guess.