<story><title>Tips from the Pragmatic Programmer (2000)</title><url>https://pragprog.com/the-pragmatic-programmer/extracts/tips</url></story><parent_chain></parent_chain><comment><author>dllthomas</author><text>&lt;i&gt;&amp;quot;DRY—Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.&amp;quot;&lt;/i&gt;&lt;p&gt;Always good to revisit original phrasings of things.  I think the catchiness of the lower-information acronym did this one a disservice.  I find myself explaining with some regularity that repetition of code is not &lt;i&gt;necessarily&lt;/i&gt; repetition of ideas, and if I have `f(x, g(y), h(z))` both here and there &lt;i&gt;but for different reasons&lt;/i&gt; then it&amp;#x27;s introducing artificial coupling to break it out into a single function.  The focus, in the longer expression, on &lt;i&gt;knowledge&lt;/i&gt; is exactly right.  DRY isn&amp;#x27;t a call for &amp;quot;Huffman coding&amp;quot;.</text></comment>
<story><title>Tips from the Pragmatic Programmer (2000)</title><url>https://pragprog.com/the-pragmatic-programmer/extracts/tips</url></story><parent_chain></parent_chain><comment><author>lliamander</author><text>&amp;gt; Provide Options, Don’t Make Lame Excuses&lt;p&gt;This has helped my career more than any other single piece of advice.  The critical mindset of the engineer can quickly lead to cynicism (especially when faced with bureaucracy).  Don&amp;#x27;t get me wrong; cynics make great advisors. But the money is in solving problems, not (merely) pointing them out.</text></comment>