I recently bought and read Coders At Work mainly for this reason; Jeff Atwood wrote this on his site:

I also realized Coders at Work can potentially serve as a job interview filter. If the next programmer you interview can't identify at least one of the programmers interviewed in Coders at Work and tell you roughly what they're famous for ... I'd say that's an immediate no-hire.

After reading the book I totally disagree with this. Most of the people in this book are old, very old. They started on PDP systems and wrote in Fortran. Most have peaked in writing C and have not gone any further. They also mainly write in emacs and use gdb as their debuggers.

They are largely academics and use functional languages. Those that are still working in modern industry are in hallowed positions where they aren't under the same project pressures that coding monkeys are. For instance one of those interviewed is at google but hasn't been checked out on a language and so can't commit code there.

This is so far removed from the modern engineering experience it is not funny. The day to day things I have to deal with are producing quality code while satisfying all the managerial demands for documentation, meetings, etc while juggling an arbitrary project deadline, demoralized resources because software is a system of perpetual crunch and leaves no light at the end of the tunnel.

The things I am really interested in is how to achieve quality code within these pressures. Because they are constant. Anything in a language and its inherent architecture that aids me in producing a quality product and easy to manage codebase and architecture within all the restrictions of a modern software shop is a bonus. I don't have the architectural freedom of academia, nor do I have the openness of timelines. I am constantly under pressure to produce things by an arbitrary date.

Engineering is never powerful enough to influence that date or make it real. Management always wants a date and often makes one up on their own. I can understand their need. They have to marshal resources other than engineering such as physical production, marketing, so forth. When engineering does give a date it is usually wrong anyway due to scope creep and how pitiful we are at estimating tasks with any degree of accuracy.

The best book I have read is Martin Fowler's Refactoring. The very next day I could apply some of those techniques and have higher quality code. In engineering terms it offered instant gratification. Refactoring is a pure engineering book. Coders At Work in comparison is an interview book about historical celebrities in the engineering field.

To me, in the past ten years or so the biggest improvements in productivity have been:

Not managing memory. I take this totally for granted in languages like Java, C# and Python.

Eclipse adding import statements with a click (please do that soon Visual Studio. Also add automated compile please ...)

Google. If I get a stack trace now, I know I am not alone, someone else on the internets has had the same problem and I google the stack trace explicitly and within minutes of browsing have the answer. When the internet was less stable and connections at businesses commonly went down, we would joke that we can't debug without an internet connection to a search engine.

Refactoring tools in eclipse. It used to be if you refactored something you would go through clean compile after clean compile. The tools make it a five second job.

I used to use emacs until about four years ago. Since eclipse matured to the level of Visual Studio it has become a fantastic tool. It is nice and stable and has a great array of tools and perspectives. It is a wonderful piece of software.

Many of the engineering advances of the last five years have gone straight into eclipse as well. For me it is not unusual to be flicking between perspectives in the one project doing multiple ant builds, junit tests, etc etc as a mini continuous integration before the code is checked in to the repository.

If someone didn't know the history of computing and the celebrities in the field then that is ok to me. For a constantly under-pressure code slinger working anonymously cube farm to an arbitrary project deadline date, it is more important to me that they have read 'Refactoring' and understand the tools to achieve it in eclipse. I wouldn't disqualify a candidate because they didn't know who created Javascript, or who is fighting over the current standards at ECMA and so forth.

From the Coders at Work book discussing why generics were added in Java with Joshua Bloch:

My mental model was "Hey, collections are almost all homogenous - a list of strings, a map from String to Integer, or whatever. Yet by default they are heterogenous: they're all collections of objects and you have to cast on the way out and that's nonsense."

Wouldn't it be much better if I could tell the system that this is a map from string to intergers and it would do the casting for me and it would catch it at compile time when I tried to do something wrong!

Bloch notes that many of the additions to Java 5 were just automating in the compiler what was being done manually before by coders in the source files. The addition of generics drastically changed Java code. Before there were casts all over the place in for loops. Now type safety is taken for granted.

To be truthful, it was rarely that a ClassCastException got past development or QA and became a runtime production issue. The casting was not really a quality issue. It did make programs look messy and generics have improved there in my opinion.

Visually, the use of generics has changed Java code drastically. You never see a loop, collection or map happen without them now. Personally I think they were a positive addition.