I think this depends on a per project basis, in some projects the code can speak for itself, any competent developer would be able to look at the code and understand what’s going on.

In projects with a lot of business logic, or projects that require understanding of a specific subject, it’s often better to write comments to clarify what’s going on. Sometimes code alone isn’t enough.

I agree and to that list I'd add:

- Performance optimizations (always worth mentioning why you ugly'd up some code for a necessary speedup)

- Kludges where you're working around something in an external library or service

can you give me any examples