Ideas Are More Important Than Code

Do you have coworkers whose shelves groan under the weight of hundreds of pounds of technical books? I do. And I always try to gently convince them that maybe they should buy books by content instead of weight:

It took me a while, but I finally came to realize that books that are heavy on ideas and light on code end up having a longer shelf-life and make more of an impact. Books about tools are needed, but books that teach the "why" are so much better. Unlike those VB5.0 and .NET 1.0 books, theory changes slowly and incrementally. That is why some books are timeless. That is why some books with no code at all are constantly listed in developers' list of "must reads". Knowledge and theory never goes out of style, unless you stop improving on it.

Similarly, in my recommended reading list, I urge developers to consider that reading The Mythical Man Month-- which is over 20 years old-- might be a better use of their time than poring over the latest thousand page technical tome du jour. This can be surprisingly difficult to get across to skeptical developers.

An alternate take on this topic is Chris Sells' the most important thing that I've ever learned is how to learn:

Still, teaching without the foundation of knowledge isn't effective. How do I gain that foundation of knowledge? I consume the available material and ask "why" a lot. If I look at a class hierarchy and it's design isn't immediately obvious to me, I ask why it was built that way and why was that way chosen over another. And to the answers to those questions, I keep asking why 'til I get to something I know already or until I get to a human reason. The reason for not stopping 'til I get to something I know is that I believe that all learning is only as affective as well as it can be tied to what you already know. How easily it is to learn something is directly related to how much you already know about related topics, so the more you know, the easier it is to learn more.

It seems a bit myopic to me that Chris states COM was too hard to learn "naturally", and emphasizes the value of asking "why", yet he can't seem to ask himself why is COM this hard to learn and teach?. Well designed systems are easy to understand. Anyone can develop a complex system that takes a week long training course to comprehend. Developing a complex system that a developer can master in a day, well, that's a lot more impressive.