How to Read a Book suggests that when you read a book for the first time you should deliberately skip-read it, unhesitatingly skipping over detail sections. -- Martin Fowler (DuplexBook)In the past, I read technical books very differently. Actually, I always read as fast as I could; however, I would also do every example in technical books. I found that if I did the examples, I would remember how to do something without needing to reference the book. This worked fine for me, but I was working off a poor assumption: I wouldn't want to reference the book.
Then, Obie Fernandez and I worked together on my first Ruby/Rails project. I had been doing fat client development in C# for the previous 2.5 years, so I had a lot of catching up to do. I told Obie I was a bit overwhelmed by the number of books I wanted to finish (Ruby books, Rails books, Ajax books, CSS [no more tables!]). He gave me a great tip: Read books to create a table of contents in your mind, but don't focus too much on the implementation details. I argued at first, but in the end I conceded. The truth was, I didn't need to know everything in the book. In fact, anything I did need to know, I would remember after the first or second time I had to look it up. All that I really needed from my first trip through the book was to know what was possible, not exactly how to do it.
Since that conversation, I've been very happy with the results I've gotten from mentally indexing the concepts instead of memorizing the text. And now the Pragmatic Programmers have made it even easier by offering their books in PDF form. With searchable versions of the books available it's now easier than ever to read a book well enough to know what's available and then search the PDF for the details when you need them.
The technique I'm describing is what DuplexBook tries to offer you by providing the summary and details in different sections of the book. I think DuplexBook is a great idea, but only time will tell if it is effective. A possible issue I see with DuplexBook is that the summary may provide too many or not enough details depending on your personal preference. Truthfully, I end up reading all DuplexBooks cover to cover anyway. I generally like more detail than the summary provides.
Do you still do all the practice exercises in the book?
ReplyDeleteUsually, no. But, if I want to get a bit more familiar with the content, that's a decent option.
ReplyDeleteCheers, Jay
Exactly true. we should always use 80-20 rule
ReplyDelete20% effort = 80% results
first skip and skim the book, our brain will have complete picture.
later read the necessary content.
if possible from end to start. this will give a tremendous effect.
I don't think there is any one right way to read a technical book. For one thing, it depends on how technical the book is. Most programming related books are not all that technical. However, some books (e.g. design patterns) are conceptually deep and require some follow-up thought. Recent research implies that for material that is not too difficult, it's best to read, then recite, either out loud or with by writing down what you think you learned. For difficult material, you first have to understand what you have read. The problem with this is you can get stuck. So in this case it's better to note your lack of understanding and move on. Perhaps you'll puzzle it out when you have the bigger picture.
ReplyDeleteI think the key is reciting. Read a chapter or section, once, review in your head what you have learned, and more, expand on what the author has written. What did he leave out? What can you add? What do you think is not quite right? etc.. I think, often, that rereading is a waste of time.