quotes_orig.txt

Rule 1. You can't tell where a program is going to spend its time.  Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. -- Rob Pike
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) -- Rob Pike
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures. -- Rob Pike
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. -- Rob Pike
"Sugar is something that makes coffee bitter when you forget to put it in." -- Anonymous 5-year old.
If one is a kind of mediocre developer but gets thrown into the team,where standards are high, the productivity of such a person would be higher than in a kingdom of spaghetti code..
"In C I never learned to use the debugger so I used to never make mistakes," -- Arthur Whitney
Joel Moses: "APL is like a beautiful diamond - flawless, beautifully symmetrical. But you can’t add anything to it. If you try to glue on another diamond, you don’t get a bigger diamond. Lisp is like a ball of mud. Add more and it’s still a ball of mud - it still looks like Lisp."
The main difference between APL and Forth: APL -> name the data, not the code. Forth -> name the code, not the data