Technical books nowadays weigh in at 1000+ pages. As busy as you and I are, how would we approach reading such monsters? Here are my thoughts. I am still struggling with a lot of this, so it is not a "science", and I would love to hear other approaches.
Preliminary step: Put a dollar value on your technical reading time, and estimate the real cost of reading the book. Take your annual income, divide by a 1000 and multiply by a factor (either less than 1.0 or greater - personal choice). This gives you the cost of your reading hour. Say your annual income is $20,000 per year. Your hour is worth $20 to your employer. It may be worth more, or less, to you - while reading and learning. If you'd rather be golfing, or snow-boarding, then multiply that by "lost pleasure" factor, say 2.0, 3.0, or 5.0. The cost of a reading hour for you is then $40, $60, or $100. If you consider technical reading a pleasure activity, then it is not costly for you. Use a factor of 0.5, or 0.1, so the cost of a reading hour is $10.0, $2.0. Whatever you do, don't value your reading hour at $0.00. No one has valueless time. Anyway, you get the gist of this. So 10 hours spent on reading a technical book costs you, say, $400, if you settled on $40 as your hourly cost.The major take-away point here is that the cost of reading a book is not the price of the book. Since some technical books may require 40 or 80 hours, you are looking at a substantial investment in time - $1600 to $3200.
Step 1: Size the Book.
In a previous blog entry I outlined one book sizing approach - other than number of pages. Essentially concepts per page, or "concept density". If the concepts per page sizing is tiny, say less than 10 (when normalized to 1000, 0.01 absolute concepts per page), consider discarding the book.
Step 2: Classify the Book.
Tutorial, Reference, Survey, Hands-On, Not hands-on. Any other criterion that is meaningful to you.
Example 1: JDBC API Tutorial and Reference. Self-classifying in the title. About one fifth the book is tutorial, rest is pure, look-up, reference. I would classify this book as low-density tutorial. Ignoring the reference part, essentially obtainable online, so it does not represent a "reading load".
Example 2: Object-Oriented Software Construction. Tutorial. Not hands-on. High density, tutorial.
Step 3: Make a Concept List
Step 4: Use concept list to create a reading plan.
Step 5: Start Reading. Read selectively according to your reading plan.
But always remember: you don't have to read the book through to consider that you have read it.
A special difficulty is posed by hands-on books. If you just plunge-in and just "follow along" doing what the author says to do, you run the real danger of burning non-trivial amounts of time (weeks perhaps), and then getting frustrated and abandoning the reading that has now become a project on its own. To really make use of a hands-on book, I recommend reading it and not doing the hands-on part on a first read. After you've read it, then you can have a rough feel for how long the hands-on portion will take. I am sure this will be hard to do when you really want to dive in and start coding and testing in a hands-on development book. But try to resist, unless you have a fair idea of how long this dive will take - a day, a week, or four weeks. Or do just a little bit of the hands on, to get a feel for it. Then a quick read. Then a second read with following the hands-on.
General Comments on "Concepts".
- The concept of "concept" is a soft concept! A concept is any idea you, the reader of a big technical work, decide is a concept for whatever purpose that is useful to you. This is purely to give you a handle on conquering complexity resulting from sheer size, and an approach to "eating the elephant". Whatever works for you is valid. No one has to agree with your choice of what you consider, or discard, as concepts. No one has to see your list of concepts. It is by you, for you.
- What constitutes one concept to one person, may require a decomposition into many concepts for another. What is ignored as a concept (may be because it is old hat already) for one person, maybe a revelation in its novelty to another. We all require different size "bites", have different conceptualization schemes, and have different backgrounds, knowledge, and experience. Your choice depends on your background, your experience, your prior knowledge in the topics at hand, and your "current store" of concepts.
- Concepts come in chunks - or conceptual networks. You can do a concept map and draw simple connections between related concepts. Computer analysts, object modelers, and database designers are familiar with concept maps. Some elaborate forms of concept maps are called conceptual models, object models, data models, semantic networks, what have you. But there is no need to get too elaborate for our purposes here, simple circles and arrows would work very nicely. This concept is related to that, it refers to this, it is a kind of that, it requires that, it affects that, it depends on that, it leads to that, etc.
- You don't have to read a book to get its concept list and concept map. Start with the table of contents, then the index, then chapter summaries - if provided, or scan through diagrams. Some authors, Like Bertrand Meyer, actually tell you at the end of each chapter, "key concepts introduced in this chapter". This is what you're after exactly: key concepts introduced in this chapter. Any form of "power skimming" scheme can allow you to generate a concept list and a concept map, may be in a couple of hours. It really pays back, in "pre-reading" the book and "pre-digesting" it.
Comments