3 ms·

The top 9+7 things every programmer or architect should now

10 points by kioub 15y ago

cycojesus 15y ago
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 15y ago
  I kind of prefer foo = bar ? bla : bli;
troels 15y ago
I see your #4 (Performance) and raise you one "premature optimization is the root of all evil" -- Donald Knuth
- asymptotic 15y ago
  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-favourite-quote-about-programming/816#816 http://programmers.stackexchange.com/questions/39/whats-your... 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 15y ago
Thank you all for your comments! I am sorry for the "now" typo ... its obviously know! BRs
rs 15y ago
The book that was reviewed is here: http://oreilly.com/catalog/9780596809485/ http://oreilly.com/catalog/9780596809485/

10 points by kioub 15y ago

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 15y ago
I kind of prefer foo = bar ? bla : bli;

troels 15y ago

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

asymptotic 15y ago
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-favourite-quote-about-programming/816#816 http://programmers.stackexchange.com/questions/39/whats-your... 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 15y ago

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

rs 15y ago

The book that was reviewed is here: http://oreilly.com/catalog/9780596809485/ http://oreilly.com/catalog/9780596809485/