My favorite optimization: replaced 10,000 lines of code that marshaled structures in a Broadcom driver for transmission to the embedded processor, with a single template of ~20 lines.
I once sped up an intern's code by just deleting a 30-line function, and doing nothing else. Doofus didn't realize our language had a highly optimized built-in sort, and so he wrote his own inefficient sort (insertion) that overrode the existing one. Poor little guy was so proud of having chosen exactly the right sort, and then implementing it based on his recollection of college... I told him to spend the next few hours just reading the documentation of the core API for our language.
Unfortunately, I forget who said it.
Isn't that backwards?
I can say this having spent months in the laboratory to learn things which were already known. Who knew that precision quartz pressure gauges were called 'manometers' in the late eighteen-hundreds? I didn't, and thought I'd invented something new for a couple months in my first year of grad school.
The adage is a good one. Reading a lot and reading widely pays off.
Who's to say an anecdotal 'employee' is any better than his 'intern'?
I was riding in a car with buddies who were much better C programmers than myself and making notes on some code I needed to do the review of the next morning. This is the code pattern that almost crashed our car:
a = some_function(i);
a1 = &a;
a2 = &a1;
calc(a2);
I was cussing a bit much[2] and front seat passenger had to look then driver got too curious. Sadly, this was the least "wrong" thing about the code. Its very hard to do a code review where you suggest 500 lines of C can be reduced to 50.
1) cannot have the guy doing code reviews actually coding, that would be improper
2) cussing in private allows positive, motivational tone in public