Brian Kernighan is one of the best technical writers around, and that statement is supportable in many ways; Wikipedia claims that The C Programming Language has been used as a model for technical writing, and certainly I have seen it favorably referenced in many contexts for its writing style.  Rob Pike belongs to a generation younger than Kernighan and Ritchie, but his writing rapport with Kernighan is obviously excellent; both The Practice of Programming and The Unix Programming Environment are truly excellent books, and they benefit from both Kernighan’s tight technical prose and Pike’s sense of cleanliness in solutions.  (Which is not to say that Brian Kernighan does not also have some clean technical solutions!)

That is to say, The Practice of Programming is an enjoyable book to read for its style as well as its content.  The content of the book consists of a collection of broad practices of interest to programmers, from style (what should you name your variables?  Where should you put a comment?) to environment (how should you choose a language?) to maintenance (what log messages will help you find a bug once the program is deployed?) and everything in between.  One of the strengths of the approach in this book is that it develops several examples of real code to solve problems.  It presents solutions that generate random prose using Markov chains, match spammy phrases in email, and parse Unix-style regular expressions, among others.  In addition to these solutions, the book is filled with examples of questionable code that purports to solve some problem, followed by deconstruction of the approach and the presentation of a much better solution to the same problem.

The only edition of this book was published in 1999, and it is showing its age.  In particular, it frequently mentions the popularity of Perl as a scripting language but does not address Python, Ruby, or any of the other modern languages that are popular today (as they were barely on the radar at that time!), and its treatment of Java and C++ are somewhat unfair as those languages have advanced significantly in the intervening years.  Even some of the pitfalls in C that are mentioned were corrected in C99.  Nonetheless, if one can look past the superficial staleness of some of the claims, the meaning of the material is still relevant.  The C++ STL may have matured significantly in two decades, but the ill-behaving collections and benchmarking your actual solution remain relevant even now!