upvote
Actually good naming does plenty to explain the why. And because it’s part of the code it might actually be updated when it stops being true.
reply
Comments are great until they diverge from the code. The "no comments, just self-explanatory code" reaction comes from the trauma of having to read hundreds of lines of comments only to discover they have nothing to do with how the code actually works, because over time the code has received updates but the comments haven't. In that case it's better to just have no comments or documentation of any kind--less cognitive overhead. This is a symptom of broken culture, but the breakage is the same kind that has managers salivating over LLM vibeslop. So I totally get where your colleagues might be coming from. Working within the confines of how things actually are it could be totally reasonable.
reply
This is honestly such a bad argument against comments.

I'm gonna note down my reasons for doing things and other information I deem useful, and if some other dipshit 5 years from now when I've moved on comes along and starts changing everything up without keeping the comments up to date that's their problem not mine. There was never anything wrong with my comments, the only thing that's wrong is the dipshit messing things up.

Doesn't matter what I do, the dipshit is going to mess everything up anyway. Those outdated comments will be the least of their worries.

reply
> the code should explain itself.

This is a good goal. You should strive to make the code explain itself. To write code that does not need comments.

You will fail to reach that goal most of the time.

And when you fail to reach that goal, write the dang comments explaining why the code is the way that it is.

reply