I'm actually a fan of the following proverbs. They are less pompous, and more humourous :<p><a href="http://theprofoundprogrammer.com/post/28552672458/text-maybe-a-clean-build-will-fix-it" rel="nofollow">http://theprofoundprogrammer.com/post/28552672458/text-maybe...</a><p><a href="http://theprofoundprogrammer.com/post/30809835982/text-race-conditions-photograph-of-a-cheetah" rel="nofollow">http://theprofoundprogrammer.com/post/30809835982/text-race-...</a><p><a href="http://theprofoundprogrammer.com/post/34818584135/text-do-not-remove-photograph-of-the" rel="nofollow">http://theprofoundprogrammer.com/post/34818584135/text-do-no...</a>
Unfortunately I only agree with a handful of these particular proverbs. The set of proverbs that I've found are truly useful to programmers would be "The Zen of Python" (open a Python session and run `import this`)<p>The Zen of Python:<p><pre><code> Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!</code></pre>
>Programming is about understanding with precision. Not about trying until it works.<p>I think you're talking about engineering, because programming is <i>definitely</i> about trying until it works.
My favorites are:<p>“A complex system that works is invariably found to have evolved from a simple system that worked.”
John Gall<p>“Enlightened trial and error outperforms the planning of flawless intellects.”
David Kelley<p>“It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it.”
Steve McConnell<p>And two quotes from the Agile Manifesto:<p>“Working software is the primary measure of progress.”<p>“Simplicity — the art of maximizing the amount of work not done — is essential.”<p><a href="http://henrikwarne.com/2012/02/25/favorite-programming-quotes/" rel="nofollow">http://henrikwarne.com/2012/02/25/favorite-programming-quote...</a>
<p><pre><code> 1. Start with the answer, then work back.
2. Don't repeat yourself. (DRY)
3. Normalize the data. The process will follow.
4. Isolate. Isolate. Isolate.
5. It worked. You touched it. It doesn't work. It was you.
6. Write for the next programmer, not the machine.
7. If you don't hate your old code, you haven't grown enough.
8. The first A/B test is your own.
9. Focus on the microseconds & the nanaseconds take care of themselves.
10. The fastest code is the code you don't write.
11. The 2nd worst programmer is who wrote what you're maintaining.
12. The worst programmer is the one who changes your code.
13. Comments don't execute.
14. The best technical co-founder is a code generator.
15. The user never knows what they want until UAT.
16. Fast. Cheap. Right. Choose 2.
17. Perfect specs or rapid iterations. Choose 1.
18. Start with "Hello World", then amend.
19. Never deploy on Friday.
20. Forget to unit test? That's a paddlin'.</code></pre>
See "The Klingon Programmer's Code of Honour" <a href="http://www.klingon.org/resources/klingon_code.html" rel="nofollow">http://www.klingon.org/resources/klingon_code.html</a> -
First on the list:<p><pre><code> Specifications are for the weak and timid.</code></pre>
> The first symptom of stagnation is preference.<p>Love this one!<p>[EDIT]: I probably didn't understand it the same way. I read it as "don't have favourites, be open to new stuff"
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."<p>[Source](<a href="https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4lXw/oITtSkZOtoUJ" rel="nofollow">https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...</a>)
Actually hoped to see more true, but satirical, statements like: "It usually takes a long time to find a shorter way." or "Debugging software is the practice of removing bugs. Programming is the art of putting them in." Currently seems more like criticising a lecture.
Back in the days of Windows 3.11, in frustration, I coined one that so far has not gained any traction:<p>"that which can be configured must be configured"<p>Just like there are few people with IQ exactly 100, there are few users for whom all the default settings are appropriate. One has to review all config panels to be sure, and I have never done so without finding one critical default or another that was just plain problematic.<p>Lesson: make defaults clear, as few as possible, and all found in one place.
One of my favourites: "I don't need to know how it works, or if it is secure, I just gem install it! Don't ask me, I'm just a web scale developer!"
"Elegant, efficient, and effective code beats any argument."<p>The scary thing is, I know people who firmly believe that, even when the argument is on code correctness.
I like this better: <a href="http://programmingexcuses.com/" rel="nofollow">http://programmingexcuses.com/</a>
(just press 'refresh')
Not really a programmer proverb, but close enough and still pretty good.<p>Customer Disservice: "We're Not Satisfied Until You're Not Satisfied"<p><a href="http://www.funnyjunk.com/funny_pictures/477940/Customer/" rel="nofollow">http://www.funnyjunk.com/funny_pictures/477940/Customer/</a>
My all time favourite:<p><i>There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.</i><p>C. A. R. Hoare