A well written book can provide the resourceful reader with a lot more than how to write software. This is something rarely done in any other teaching medium, and in my experience compliments all other instruction quite nicely.
A technical book generally starts with a high level summary, and works down into details gradually. It will have an introduction, providing direction about the value of the technology being studied. Don’t skip over this section when you are first reading. It should provide for you an understanding of how the technology came to be, the objectives they are trying to achieve, and some guidance about how to learn from the book. Many books are not meant to be read cover to cover. An introduction often provides guidance.
Second, read the table of contents. The table of contents is like a road map. It shows you all the big highways to get from point A to point Z. There is little detail, and you can’t really start solving problems with the information you get from the table of contents. But, you have a pretty good idea of where you are going.
Third, determine the order of chapters you want to review. If the chapters build on previous chapters, you may need to read them in sequence. If you already have necessary knowledge, there may be chapters you can skip. There may be specific areas of a tool you wish to work on, and ignore everything else.
Fourth, get into a chapter. Hopefully, each chapter will have an overview of what they are going to cover in that chapter, and tell you how that chapter fits into the rest of the book. It may provide information telling you to go to a previous chapter for more foundational work. Regardless, it should tell you what this chapter is going to accomplish. If not, perhaps you need another book.
So, now you are into the details, which is why you thought you bought the book in the first place. If that’s the case, then you probably don’t need a book. You can maybe pick it up on some web training or simply use google for examples. The difference here is that you now have a mental framework for how this new detail content fits into the overall strategy, helping you to thing tactically instead of just syntactically. From a good book you should not just learn syntax, which is the norm from a google search. You should learn why it works, when to use it, what other options you could consider, and how to make selections.
If I’m reading a software book I find it especially helpful to have a program, or work on the sample programs they provide. So, when reading the actual syntax I like to do it actively, so that it make sense. I can actually make it run.
Maybe this is too simplistic. Those of you who already work with books know how to do this. I am finding that many of the new generation of coders have been taught to only get materials using short cuts. That is the audience I hope to reach. It’s hard work to learn from a book. I have found that those who do learn from some reading do not develop strong skills as quickly, or sometimes not at all. At least, that has been my observation.
Cheers,
Ben