Fred Brooks' seminal work, The Mythical Man Month, is rightly considered a classic on the topic of software development. Although it was originally written over 30 years ago, it is still a remarkably insightful and interesting read today.
The apparent timelessness of Brooks' work is surely due to its focus on managing and improving the software development life cycle, not on specific language techniques. Brooks' anticipates some of the tenants of extreme programming by suggesting rapid prototyping, extensive use of test cases and continuous customer interaction. He is optimistic about the benefits of object oriented development despite some initial reservations to the idea of keeping the code within components hidden from plain view.
He discusses the difficulties of estimation, the utility of keeping a project workbook (kind of a proto-wiki) and suggests a "surgical" team structure to maximize productivity. And of course, he presents and later defends the so-called "Brooks' Law", that adding people to a project that is late will only make it more late.
In the epilogue to the 20th anniversary edition of The Mythical Man Month, Brooks discusses how it has become impossible to keep up with all the new developments within the software industry:
The computer related intellectual discipline has exploded as has the technology... Today my intellectual life has seen me regretfully kissing subdiscipline interests goodbye one by one, as my portfolio has continuously overflowed beyond mastery. Too many interests, too many exciting opportunities for learning, research, and thought. What a marvelous predicament!
While marvelous, this is a predicament and as such, begs a solution. Brooks' hints at one when he discusses the difference between the essence and the accidental in software development in the chapter, "No Silver Bullet". Briefly stated, the essence of software development is the modeling or description of a problem into the software realm, while the accidental is the actual implementation of the essence (or specification) into working code. Brooks' estimates that 90% of the effort in a project is the essence. And yet we spend a lot of time trying to maximize the 10% of the accidental.
Based on this ratio, if object oriented programming can streamline the 90% of the essence by providing a good conceptual framework to plan a product around, then it is a worthwhile addition; however, writing a program using an object oriented language without following object oriented concepts is not in and of itself an advantage.
Let's return now to our marvelous predicament. It is almost tautological at this point that one developer cannot possibly master all their is to know within the field. Yet, most developers are by nature are very curious (a point Brooks makes early on) and so they will want to keep learning new things. So some selection criteria must be used to winnow the available choices. Looking to Brooks, a good criteria might be to concentrate on learning new things that let you more effectively attack the essence of software development, not the accidental.