No pride, no prejudice: Effective Java

While reading programmers' blogs you can be exposed not only to shiny technical stuff, as well you can meet author's private opinion. It's positive, as human being we want to share our opinions with others. But some opinions seem weired - and only possibility is to get used to that. One blogger dissed proggrammers' meetups, other advocated abortion, another one prefered null checks over Optional, million others actively hate statically typed languages. Not mentioning Emacs fans...

Some time ago I read a blog post in which author rejected idea of reading "Effective Java". Blogger had explained that book must be clearly outdated as 2nd edition was released in 2008 and he is not going to loose time for reading things like string concatenation vs using StringBuilder.
Well...

Fortunately this classical book is easy to defend, even for not such-a-proficient-blogger like me.
Well recognized Java bestseller is not really about outdated micro-optimations on low layer (which btw may also be a good topic to know). It is not about what is different from C in Java.

This book introduces readers into variety of interesting topics.
After reading you will (not only) be more aware of why immutability is important in contemporary software, how to structure data better, or how to use compiler to ensure type safety to work for your benefit. It will encourage you to use language constructs that support safe coding (eg. using enums), name things correctly (like use static factory methods) and depict constructs that are problematic (eg. clone). And explain variance in generics... :D

My personal observation is that Bloch's book was for some Java guys a first step into typed functional programming with Scala or even Haskell. I have seen lot of smart who followed this path. They could of course years ago assume that their knowledge of Java and enterprise technologies was good enough and they do not need to read one more book on `efficiency`.
I think that they had a very good and respectable attitude to their own knowledge.
Be like them. Do not believe you already know everything, rather as a software engineer you must be open to learn, read and try new things out. And sometimes read 10 years (or even more) old books.