I had high ideals when I started working here. The entire code base was practically devoid of comments. Its been 5 years and it is still practically devoid of comments. I have become like them...

If it was difficult to write it has to be difficult to read.

Ah well high signal low noise is a thing.
I find that I comment way less since I joined this company too. Part of it is because I'm Go you tend to be obvious and not hide magic. Part is because it is discouraged a bit by colleagues.

Still if there is ambiguity, Some weird edge case or exposed API's a single line of comment is warranted and often super helpful in IDE

@hjk101 same. I do comment, but mainly for critical things that are a bit tricky. To give the code credit it does have very descriptive non-generic naming. So most of the time I can figure out the purpose pretty fast.

Comments are stupid and are out of date as soon as you write them down.

Good! I feel your anger take your weapon and strike me down and your journey to the dark side will be complete….

Writing comments in your code "just because" is such an anti pattern!

Your code should be expressive enough to explain what it does and why it does what it does.

As a last resort and failing the above, leave a helpful comment but only as a last resort.

Comments go stale, and always end up being wrong, or worse, misleading

Also tests > comments

If the code is crap, the solution is better code. Not comments.

Use good names and only comment when the logic is complicated or when the change was demanded of you and you know it will cause problems later.

It may take some time to change the culture of your team, but it's worth the effort. Well-commented code is easier to understand, maintain, and debug. In the long run, it will save you and your team time and frustration.

https://drift-hunters.org