There is one book that is about 45% really great and actionable content. How To Win Friends and Influence People by Dale Carnegie http://www.amazon.com/How-Win-Friends-Influence-People/dp/1439167346/ It combines lessons in listening, establishing rapport, negotiation, consultative and Socratic selling. I say 45% because about 5% is name dropping the names of well known people in the 1930's USA and about 50% is a set of standard business letters. I have been to many courses on these topics, and all of what they had to teach is in that one book.

To all those who don't see the big deal in shaving 100 or 50 msec off page load time: see: The Economic Value of Rapid Response Time http://www.vm.ibm.com/devpages/jelliott/evrrt.html and the two articles that preceded it "Factors Affecting Programmer Productivity During Application Development" IBM Systems Journal 23(1): 19-35 (1984) "Interactive User Productivity" IBM Systems Journal 20(4): 407-423 (1981) http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/t/Thadhani:Arvind_J=.html To summarize: the quicker the response time to the human, the better the human can stay focused, keep on track, and exploit short term memory, rather than returning to the task at hand from a restful or wandering state of mind. QUESTION: Is there such a thing as a too fast response time? ANSWER: My experience is yes, when there is not enough new or changed on the page for the user to notice that in fact the result is back. In one text mode application, during a lengthy calculation process I put up a progress bar of *'s as it worked and then erased them when the calculation completed. As PC's got faster and I tuned my code, the recalculations dropped from typically 40 seconds, to 20, to 3, to less than 0.1 second. At that point I started getting calls from users that the "process" key stopped working. However, if the user held down the process key, the row of *'s would flicker, indicating that it was working, displaying *'s and erasing them, within the typamatic repeat rate of the keyboard. I added a "processing complete" text message to "solve" the "problem." I would have thought that the following HTML performance tip might no longer be necessary, but it is: Use explicit width tags in HTML table definitions. e.g. WIDTH="50%" This is especially true if the table will be very long. Otherwise, the HTML renderer does not know how to render the table until all the content has been received.

A large insurance company implemented a LIGHTS OUT Datacenter in the 1980's. All staff worked outside the room. Tapes were robotic. Printers were outside. They really ran it with the lights completely out. An authorized person opened the door, entered and flicked the switch next to the door to turn on the lights. What was actually flicked was the EMERGENCY POWER OFF for the data center. Two water cooled mainframes, coolant distribution units, A/C units, all the minis, all disks, communications controllers, modems..... Coming back up took a few hours. At least the HALON manual immediate dump switch hadn't been flicked.

I use for COPY and for PASTE. Works for me in all Windows apps, and most things in UBUNTU.