

The top 9+7 things every programmer or architect should now - kioub
http://www.javacodegeeks.com/2011/07/top-97-things-every-programmer-or.html

======
cycojesus
it's "know" with a K.

1\. I understand this as "don't wait for perfection before committing", not
"try to improve every code you checkout". If I have no good reason to touch
some code I won't, even if it looks ugly (and I'll be dealing with some
horrendous things in the coming months.)

2\. Simple code is boring. Boring can be good. Code that I find beautiful is
more clever than simple (as in, after that "AHA!" moment the cleverness
appears that would have required tons more simple code when here these 2 lines
do the same.) I find

    
    
        foo = ( bar ) ? bla : bli;
    

much more beautiful than

    
    
        if ( bar) {
            foo = bla
        } else {
            foo = bli
        }

~~~
troels
I kind of prefer

    
    
        foo = bar ? bla : bli;

------
rs
The book that was reviewed is here:
<http://oreilly.com/catalog/9780596809485/>

------
troels
I see your #4 (Performance) and raise you one "premature optimization is the
root of all evil" -- Donald Knuth

~~~
asymptotic
I'll see your out-of-context quote and raise you the more subtle, sensible,
and actually correct quote from Donald Knuth.

[http://programmers.stackexchange.com/questions/39/whats-
your...](http://programmers.stackexchange.com/questions/39/whats-your-
favourite-quote-about-programming/816#816)

    
    
            There is no doubt that the grail of efficiency leads to abuse. Programmers
        waste enormous amounts of time thinking about, or worrying about, the speed
        of noncritical parts of their programs, and these attempts at efficiency
        actually have a strong negative impact when debugging and maintenance are
        considered. We should forget about small efficiencies, say about 97% of
        the time: premature optimization is the root of all evil.
    
        Yet we should not pass up our opportunities in that critical 3%. A good
        programmer will not be lulled into complacency by such reasoning, he will be
        wise to look carefully at the critical code; but only after that code has been
        identified. It is often a mistake to make a priori judgments about what parts
        of a program are really critical, since the universal experience of
        programmers who have been using measurement tools has been that their
        intuitive guesses fail. (…)

------
kioub
Thank you all for your comments! I am sorry for the "now" typo ... its
obviously know!

BRs

