Comments

• comments distract from the code and are too easily lost in conflict resolution, or moved in reformatting
  • the initiated do not need to re-read the comments
• use self-documenting names in preference to comments, add a new function if necessary
  • this is of more use to the uninitiated
• when working on a ticket, that can be the decision record and commit messages should already refer to it
• the readme doesn't have to be behind a pull request wall, it can simply contain a link to the wiki to make documentation more inclusive
• when working on legacy code, assume it's all there for a reason even if it's bad code
  • effectively this is Chesterton's fence when the original motivation has been lost
  • so don't remove something unless it's getting in the way of making progress on the current ticket

Although

• certain individuals need to be spoon-fed, and will raise a huge damaging stink when they jump to the wrong conclusion, so it's regrettably worth humouring them even though it may patronise others
  • e.g. some can't fathom a world where you only work paid hours, avoid stressful crunch times by getting ahead of the curve, have plates spin themselves and so on