Books (or any good content you consume) have beneficial side effect of teaching you a few add-on things. Things that you had not consciously aimed to learn from that content.

For example, when I read the book Effective Java (Joshua Bloch), the learning that persisted or stayed more with me was not about better usage of Java’s features(factory methods than constructors) or defensive programming (Date), etc. but about the author’s discussion about designing APIs (AbstractSet). And it has been applicable beyond Java. When I started the book I primarily got hit by enum, Date, array, objects handling their memory (setting the object to null after you removed so that it’s easily GCed.). And it was the learning or takeaway I was looking for. But I certainly did not expect to be so impressed by something like discussion about API design. First of all I did not even expect to read anything about API design. But the discussion has taught me much more than the book taught me about any particular Java feature. And this is transferable to other areas/ technologies. In fact, possibly because it has relevance beyond Java, the learning is still relevant to me after 10 years of reading the book.

Similarly one strong point I learned from the Gang Of Four Design Patterns book and Martin Fowler’s Refactoring book is about the importance of naming things properly. When we name things well it solves a lot of problems. It gives a shared vocabulary and it gives clarity of thought and adds efficiency to discussion or exchange of ideas. You must have read that to call things by their right names is the beginning of wisdom. And it is so true that it is applicable everywhere. If you are able to name something properly, you can associate the name with the concept of that thing. And those concepts become concrete. They get a recall value (associative memory). You can immediately understand when someone mentions that we can use factory pattern here or we need to extract method there. But it is not limited to that. For example, if I mention some cognitive biases like say selection bias, availability or proximity bias, anchoring then those concepts are immediately recalled or fetched in your mind- provided you know those concepts, have associated these names with those and have ingrained these names.

Now the question is whether we can deliberately learn these things. First of all these are all mostly side effect kind of learnings (although all the books mentioned teach these things with extra focus- for example, GoF books spends a lot of time how the content about a design pattern is structured- name, applicability, consequences, etc.). But my point is we don’t pick up these books with the intention of learning about these things- you pick up Effective Java to learn more about Java’s effective usage than about to learn about API design. So let’s call these as bylane learning. Can we condition ourselves to maximize this bylane learning then?

I believe it comes to things like reading comprehension kind of exercises. Have the context of discussion in mind, then focus on what is being discussed in that module or paragraph, see how relevant is it in the context, and try to see how applicable is it outside the context. The last point about applicability outside the immediate context- relevance cross-context- is a bit difficult to manage in the moment. So my practice is to underline these things in books (make simple margin notes) and let the diffused mode (not the focused mode) find the relevance of that idea in other contexts.