The article&#x27;s advice is rather generic, though it did bring up some interesting responses.  The rule about comments in code elicited a minor controversy, but I tend to agree with the sentiment that adding comments is more worthwhile than not.<p>The program logic may be clear to the author but there&#x27;s a good chance it won&#x27;t be to others using it, especially when 6 months later I&#x27;m one of those &quot;others&quot;.  At that point it&#x27;s usually easier to determine if a comment really clarifies things and if not remove or modify it.<p>I&#x27;m surprised not much said here about rule 10.  Giving feedback to team members is an essential part of teamwork, e.g., certainly it can&#x27;t work if problems with code aren&#x27;t expressed.  However I think what the author is getting at is the fine line between &quot;criticism&quot; and &quot;critique&quot;, the latter meaning communication re: mistakes, etc., in a constructive, generous and objective way.<p>Without due care in expression, teams risk degenerating into factions arguing over who&#x27;s &quot;right&quot;, who&#x27;s to blame, and there progress grinds to a halt.  It&#x27;s always obvious when other teams are in this state, but frequently we don&#x27;t see it in ourselves or happening in our own group.  Mastering the art of critique, including self-critique, is hard, but an amazingly valuable skill to learn.