Code only says what it does
So many times this.<p>"Clear code shouldn't need comments" - clear code can make it easy to see <i>what</i> but it can never say <i>why</i>. Let me know what corner cases you thought about when you wrote this.<p>"The comments are in the commit messages" - almost nobody <i>ever</i> goes looking for them there, they're effectively invisible from `git blame` when they <i>remove</i> lines, people rarely make fine grained enough commits to be able to target specific lines or blocks sufficiently with context.<p>"Nobody ever updates comments, so they're always out of date" - don't hire such people. It is an crucial task <i>resolving</i> the meaning of comments to make sure everything still makes cohesive sense. Neglecting to do this will often lead to commits that don't quite grok any subtleties of the original design. Don't make the <i>reader</i> of the code do the job of trying to piece together the scattered history of 5 different people's intentions. Of course, it's also useful to try to keep comments as close to the code in question as possible so that references which need updating are obvious to see.