Something I learned from a great mentor when I was an intern in college. This probably applies best to those of us who work for non-software companies, where your boss or boss's boss is not an former programmer and doesn't understand how things work...
in reply to Which non-Perl books made you a better (?:Perl )?Programmer?
Find the management books on your boss's (and his or her's boss's desk), go sit in a Barnes & Noble for a couple of Saturday afternoons and read them. Even if they are awful, at least skim through them to get the jist of what your boss and the boss above them have read.
While this will not make you a better programmer. It will help you understand how they think when they make a (in your mind: dumb) decision. If you know what they are thinking when making a bad decision, you have a better chance of steering them away from it tactfully without causing a big fuss. And that is the most important part, doing it tactfully such that you make your boss think they made the newer (better) decision themselves. It will keep your group running more smoothly because of the better decision and your boss will be happy. A happy boss gives good reviews and raises/bonuses. :-)
I know this concept is in "The Mythical Man Month" but knowing exactly the books and ideas your boss reads will put you in a better position to change bad decisions to good decisions while not coming off as a know-it-all. (Remember, no boss likes to be shown up, even if they realize they were making the wrong decision... ego drives most people in that situation)
As for the best (non Perl) programming book I have read... it is hands down the Sybase Performance and Tuning Guide. After reading that, I could have serious database level conversation with my DBA group and they trust my knowledge. Now when I work with DBAs, I have a sort of 'street-cred' and they usually trust my idea of what I want and do it instead of wasting time double-checking everyone's new table schemas and such.