Although Code Complete may be showing its age a little bit (I've only read the first edition), all of these books are relatively timeless.
(Caveat: I don't think I've read more than an excerpt from Don't Make Me Think but thinking about usability is important if you have, well, users. I own at least some edition of all the others and I've read them at least once each, some of them not so recently).
What you learn from them may depend on the kind of software you work on and the phase of your career, so it's probably worth going back and revisiting them every two or three years.
Programming Pearls is, in a way, a book of war stories, and while the specific solutions he had for his particular problem constraints, you'll probably benefit by learning how he thought through a problem. Squeezing space and time are still problems we face as developers, though certainly the constraints we face are a lot less tight for many categories of problems. The book also covers testing and debugging topics whose details may change, but what has to be done doesn't change much.
The Pragmatic Programmer isn't really about code, but about craft, and so the technical examples are mostly illustrative. It's also something you can read in a few hours and if nothing else will hopefully drive you to think about why you do things the way you do and whether you can do better.
The patterns and refactoring books will only change meaningfully if you change programming paradigms; these two books assume an object-oriented approach. While the refactoring book probably translates pretty easily to, say, functional or declarative paradigms, there are probably better books on say, functional programming design patterns if you're working in languages like OCaml, F#, Haskell or similar. And you'll probably have to solve similar problems to those identified in the patterns book even if you work in a functional paradigm; the style will probably be different.
Reading these books will ultimately be a test of how you translate specific examples into general practice; if you look at every programming reference as a simple how-to, you may not get much out of these books. (I remember looking at the Design Patterns book when I was a C++ newbie and dismissed it because some perceived problem I had wasn't obviously solved by whatever chapters I was skimming, which was rather shortsighted; it meant more to me once I had been doing things the hard way for a little too long).
These are books that will hopefully impact how you think about software rather than serve as instruction manuals on how to write code.