In response to http://blog.builtinperl.com/post/must-read-books-for-perl-programmers, with apologies: Perl programmers, in my experience, tend to know Perl very well. They don't need to know more Perl. However, having often come from self-taught background, the larger field of CS seems to be what's missing, and they tend to take refuge in the Perl camp. So here are my profoundly biased picks.

Hardening Linux by James Turnbull -- http://www.apress.com/9781590594445

There's a mindset that Linux is secure if you keep it up to date, but if you pay attention, major company after rmajor company (and government) gets taken out. Linux is configured very soft by default. Defaults of allowing root ssh logins, runlevel, and so on are designed for low security desktop systems. Those are some obvoius ones, but Turnbull has a list of easily 100 similar things to harden on your public facing server. Perl programmers traditionally came from a paranoid sysadmin background, but if you didn't, this book will get you half way there (then watch DEFCON talks online and feel your parania continue to grow as you realize that nothing, nothing is safe).

The Cyberiad by Stanislaw Lem

"Fables for the Cybernetic Age" -- a series of shorts with the same characters that explores machine intelligence, unintended consquences, arrogance of creation, and personality in technology in a wonderful quirky but academically informed way. After reading the works of AI pioneers like Marvin Minsky, this book is relavent, accessible, and a treat. Just as everyone should but already has read The Mythical Man Month, also must we think of personality and human fooble while working in technology, and this book teaches that.

Object-Oriented Design Heuristics by Aurthur Riel

I can't say enough good stuff about this book. One summer in the early 90's when I didn't have Internet access, I spent a lot of time camped out in the St. Thomas University library reading CS books and decided I wanted to read books on OO and discovered this gem. Design Patterns and others can't hold a candle to this. The author gets you spiritually in touch to the complexity of the topic, and the uncertainty and trade off and conflicting rules of thumb. In my experience, Perl programmers dissmissively claim to know OO, but have divorsed the concept of polymorphism from the enormous body of work from the C++ era on architecture of large systems. This is like claiming to know your maths because you've mastered your addition tables. Exposure to a solid treatment of OO Design/Analysis would do more to improve the quality of Perl out there and improve Perl programmers than any other single topic, and this is the best treatment.

The SNOBOL4 Programming Language, 2nd ed, by Griswold, Poage, Polonsky

Perl prides itself on its pattern matching, but SNOBOL4 mixes pattern primitives with the core language, allowing programmers to easily write goal-directed, back-tracking, capturing *code*. Pattern match (full stop) is a first class data type that other functions can operate on. Until Perl successfully steals this (which would be hard to do -- just as its hard to simply bolt OO onto a language), it'll be good for Perl programmers to kno where their language actually stands with respect to one of its main claims to fame. It's also fun to marvel at how much of the modern Perl stuff we have existed in the 60s (user defined operators, for one). Like Perl, SNOBOL4 was used for text processing, relied heavily on its built in hash type, and its programmers enjoyed golfing. There are undiscovered roots here that need to be connected with.

The UNIX Programming Environment, Kerningham and Pike

We praise the modular, tool approach of Unix, but with stuff like systemd and apt (which doesn't understand major/minor versions, a fundamental and important concept in Unix library design), we're getting further and further from Unix roots. Modern Unix code is increasing looking like Windows code. Writing effective Web apps and busines slogic requires understanding and making effective use of the appropriate OS primitives. Without a grasp of what all of those primitives are and how they work, a programmer is going to throw more and more abstraction at it, and often the wrong abstraction, and write expensive, inelegant solutions to problems.

The Structure and Interpretation of Computer Programs by Ableson, Sussman, Sussman (or alternatively Higher Order Perl by mjd)

Teaches problem solving of a much higher level. There are programming tasks that are hard because the code that is the mess and there are hard programming tasks because the task requires novel CSy problem solving. This keeps the latter from turning into the former and still failing. 'nuff said.

Old home computing magazines, such as http://www.atarimagazines.com/

... back from when computing was new, exciting, and fun, and any little idea was worth exploring and playing with. This is the mindset that programmers need to be in: courisity and joy. Rediscover that. You won't get far in anything unless you give yourself permission to take interesting parts of the system and play with them and explore them. Curiosity is an important and natural instinct, guiding us towards what we don't fully understand and leading us to master it. Play is easily half of work. Knowing how to do that effectively makes us productive workers. IBM mainframe camps, Microsoft camps, and other overly seriously sometimes get too far away from this and become rigid, risk adverse, shallowing in ability or willingness to explore, and just plain stale. Look for the small to medium sized program listings and skim through the explainations of a lot of them. Take the ideas of exploring -- and sharing your explorations -- with you.