An pproach for learning from books

[Terpsfan]

Everyone has their opinion on programming books. Some feel they make great paper weights, others good for putting you off to sleep, still others find them indispensable learning tools.

I find myself getting frustrated because it seems to take me a long time to get through a book. I'm thinking my approach maybe wrong. As I read a chapter, I do the code examples (yes, I type out the code on my own computer). As you can probably infer, this is a very time consuming and tedious process. However I tend to actually learn quite a bit from actually doing it.

Or is it better to just read through the chapter, glean what you can from it, then do the code examples and then move on to the next? OR just read the book, glean the code examples and not actually do the code examples.

I'm just interested in hearing other viewpoints from others on what works for them.

 

[EBGreen]

I read the chapter, read the code examples and tried to find some problem that I've had in the past (or better yet have now) that could be addressed using whatever technique is being discussed and try to code a solution.

[blue]"Well, once again my friend, we find that science is a two headed beast. One head is nice, it gives us aspirin and other modern conveniences,...but the other head of science is BAD! Oh, beware the other head of science, Arthur; it bites!!" - The Tick[/blue]

 

[screwloose]

SQ3R

SURVEY - gather the information necessary to focus and formulate goals.
QUESTION - help your mind engage and concentrate.
READ - fill in the information around the mental structures you've been building.
RECITE - retain your mind to concentrate and learn as it reads.
REVIEW - refine your mental organization and begin building memory.

 

[willir]

Omega36

First make sure you are reading a book at your level.

If the level is too hard, consider purchasing one at an easier level. Absorb it, then move on to the more difficult. If the text is too tough, it will be a (insomiac)*-1 experience.

If the book is too easy, the book will become another dead tree planted in some obscure bookshelf.

You need to be well rested, fresh and able to concentrate. You will glean what is important to you. If it is not important to you, stop and think why -- too hard, not relavent. If the section is too hard. Bookmark it for a return visit.

If this is for a test or certification, then as Screwloose states, recite and review galore.

The good books will be well thumbed as you work with your coding. The not-so-good will gather dust.

Note which books have been useful in the past. This is the type of book you should look for when moving on to your next challenge.

Lastly, technology changes, languages improve. Eventually that well thumbed, faithful, trusty text book is destined the bit bucket. (I still havn't figured out what to do with my old dBase books) ... with one exception. Books that deal with design and theory will always be useful. And it is not a bd idea to review them over time. I find myself picking up new nuances as I learn from my past experiences.

Oh, a hint. I am not a health nut, or whatever, but I have found taking fatty acid supplements such as omega-3-6-9 vitamin pills for a couple of weeks really help me focus on the nitty-griitty stuff. Weird huh???

 

[lionelhill]

You've answered your own question: "I actually learn quite a bit from actually doing it". If you're learning, and happy you're learning, keep doing it. If you've got enough time, don't worry that it takes time. We're all different, so everyone has a different learning technique. I'm deeply sceptical, though, of those who say they can learn without trying anything out on their own computer.

I find most IT books utterly, utterly useless; and these are the books that I see on other people's shelves (and my shelf too, some of them), still as new-looking as the day they were bought. Willir's right: a good IT book looks like it's been through a swamp backwards, and has frayed, browning edges. The ones I find really useful are:
(1) basic theory books: algorithms, methods etc., independant of platform and language.
(2) simple reference guides to hardware, system calls, and language syntax. These should be over-breakfast revision reading ("good gracious, I never knew you could do that by a single instruction! I've been using my own function unnecessarily")

 

[CajunCenturion]

lionelhill Your point 2 is a good one. I know that I've read far too many posts in the technical fora that call for a built in function or command that the poser has no idea exists, and a simple RTFM answer. Simply browsing through the function reference section alerts you to what tools have been built into the language. It's not important that you learn how to use each and every function, but it is good to be familiar with what's available to you. When you need the specifics, then you read about that function in more detail.

You would never expect a carpenter to go onto a job without knowing what he has in his toolbox. Why do programmers and system administrators think they can go onto a job without knowing what is in their toolbox?

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Terpsfan]

Thanks for your replies...

I can't say that I have found one computer book useless, although some are better than others. I can usually glean something of value from each one. Each has a different point of view. There's always a better way to build a mousetrap. I am going to adjust my approach on reading them by concentrating on learning more about the theory then driving myself nuts with the code examples. Doesn't it suck when the code examples don't work!

Centurion I like your toolbox metaphor. However there are literally thousands of functions to call or tools to use for a programmer while a carpenter may only have about 50. No programmer knows every aspect of what's in the language. But yes you should familiarize yourself with as much as possible.