Look, if you've seen the shit I have, frankly it's not a given

Comments are by definition not part of the code.

And no, I never trust the author - even if it was me 6 months ago.

Not to mention all the other programmers that might have fiddled with it. Not mention changes in the code since it was written, where the comments weren't updated.

As a maintenance programmer with 35 years experience, the first thing I do is delete the comments. My experience says they get in the way and can't be trusted. Read the code, understand the code, and figure why it's doing what it's doing. Don't worry about what it might have been doing 10 revisions ago when the comments were last updated.

We're kinda breaking from the shitposting theme here, but this is good discussion

Honestly unless you're writing DSP or 3D engine code, micro-optimisations are an absolute waste of time. Either you're working in a low enough level language that the compiler is going to do a better job than you anyway or you're working in a high level language where such optimisations are pissing in the wind

And if you're doing DSP shit in 2026, let me talk to you about the good news of zig

Most code isn't unreadable, because it's optimized for performance, but rather because it is needlessly complicated and should be refactored. And then reducing this complexity is likely to improve performance as well.

For example, you might draft out an algorithm with a nested loop, and then you look at it once more and realize that it can be done with a single loop. That's very likely easier to grasp and massively better for performance, too.

If you do need to make code unreadable for performance reasons, then absolutely do make use of comments. Although I would still recommend making it understandable without resorting to comments, if possible.

Function, variable and test names can help to explain a lot. Error and log messages can be used to write out really clearly what is happening. And they have the huge advantage compared to code comments, that they show up in at least two places, which makes them more likely to be read and updated.

As someone else already wrote, the why should still be explained with a code comment. It rarely makes sense to explain implementation details in log statements...

Oh thanks I see it now

First of all, most of the cost of a system comes from maintenance after implementation. So the idea that "an engineer can read it 40% faster" isn't as trivial as you make it sound.

Secondly, well laid out code that doesn't need to be commented is generally simpler to write, easier to test and easier for the original developer to conceptualize when he's writing it. I've seen lots of programmers get lost in the complexities of their own approach because they don't organize their code properly.

Finally, my understanding is that modern compilers optimize lots of things automatically, probably better than an engineer would and on all of the code. Write your code for the human to read it, let the compiler do its thing, and optimize by hand only that tiny percentage of code that causes performance issues.