1–10 of 84 posts
Do you read it in one go and later try examples or go through entire book by trying all examples?
Do you read the entire book or just the part to get the job done?
What methods/techniques have you found useful while reading such books?
1. Skim the whole book. The goal here is to learn basic concepts, keywords, and the structure of the book.
2. Start coding, refer back to the book as I encounter things I don't understand.
This works better with paper books, because it's easier to remember where I saw something ("upper corner of left-hand page next to diagram, towards the end of chapter 10").
That said, I may skim sections that are less relevant to what I want to know. For completely new languages / API's I am going to need to do some coding, but 'exercises' seem to be their more so people will use books as textbooks than directly useful on their own.
2) Most programming authors do not write about tradeoffs. They write about language syntax or library features and end up being (inadvertent) evangelists. All languages have warts and problems that books don't talk about. To supplement book reading with a dose of real-world realities, always corroborate with forum discussions, stackoverflow, etc.
3) Instead of reading 1 book, go through 2 in parallel from different authors. E.g. read about monads chapter in 1 book and find the same topic in another book. Different authors explain concepts in different ways which can help reinforce the learning
1. Read the whole book in one sitting, to get the big picture in my head, and build a mental model of the thing.
2. Implement a toy project using the thing. Maybe an hour or two. Go back to the book for details as needed.
3. Look up something once or twice when building my first real project.
4. Never read the book again.
In spite of the short time I spend with them, it’s so valuable to be able to read at high speed, on paper, a comprehensive bunch of code and concepts.
Typically I read the book a chapter or 2 at a time mattering how much information it covers. Mattering how technical it is I will write down every word I either don't know or second guess.
I will read over the code examples fully. At the end of the chapter I will try to recall the code example in my head, and see if I can replicate it. Mattering how good or bad that goes I will then move on or write the code out.
I keep notes the entire time I am reading. It helps keep me focus on the subject matter. My mind loves to wonder to much, and I have to beat it like a alien from the fourth dimension.
Also the notes act as long term reference as well I can review them every night for roughly a month to make sure it all sticks.
Then I read a book on it, cover to cover.
It's much easier to get everything to "click" when you've already tried to solve the relevant problems yourself.
Then continue working with it, and every now and then read another book cover to cover, for important things.
After I think I have mastered the basic chapters, I will continue reading the subsequent contents. I won't try to understand everything in the advanced parts. Instead, I just read some useful content and treat other content as a technical dictionary so I can refer to it in the future.
I like learning a language/tool as quickly as possible, and then try to use it more skilled.
I look at the table of contents carefully.
I then read the whole book quickly to get oriented. At that point I make a judgement whether it's worth more time and effort.
Still here? Then I reread any chapters that relate to performance, because those chapters usually give a clear view of interesting issues in the subject system.
Then I do one or two of the problems / examples / demos. I do my best to avoid downloading and running them; rather I take the time to type them over; it helps me cognitively to understand what I'm doing.
Then I evaluate whether the material I'm learning will help me solve current problems, or give me ideas about solving future problems, or not.
I put the book in my Safari queue if it's relevant to either current or future problems. Then I go use what I've learned.
I wish I could say I wrote a quick personal review of every book. But I don't.
This works pretty well for me. Safari is a great way to read tons of books, because, well, "tons of books." They don't take up shelf space or have to be moved, or recycled if they turn out not to be useful.