How I Read Programming Books

I am not sure what started the trend or why it continues. Exercises are where the learning happens for me. Perhaps well crafted exercises are more difficult to write than programming language documentation/cookbook style books? (which is what most of these books are)

There is less focus on books as a teaching method, and rather just a collection of manicured examples and well ordered documentation. (which are also valuable, but not a great way for me (and others, I suspect) to truly learn a language or technology)

In this regard Practical Common Lisp is a killer book. Definitely one of my favorites. It's really a pity that there aren't many other books mimicking its style (recommendations are welcome).

Personally, I do most of my reading on an e-reader, in bed, before going to sleep. I think the approach suggested here would require my re-readings to take place closer to a computer.

Are exercises useful? Yes. But doing a significant fraction of them increases your read time substantially. It pays off, but now there are other ways (at work, or in open source) to learn things that are less structured but still effective.

Exercises help you get a deep knowledge of the material, but the market doesn't reward that. You're better off with a more shallow knowledge of a lot of things.

The old cycle for learning X:

1. Get an X book. Do a basic reading to get the vocabulary and core concepts.

2. Decide if you're interested in deep knowledge of X. If yes, continue. Otherwise, terminate and choose a new X.

3. Do the exercises in the X book. This will take a while.

4. Do some X at your job.

5. Read the research papers if you want to get to the frontier.

New process:

1. Get an X book. Do a basic reading to get the vocabulary and core concepts. (Same as above.)

2. Decide if you're interested in deep knowledge of X. If yes, continue. Otherwise, terminate and choose a new X. (Same as above.)

3. Get a job doing X. The knowledge and vocabulary learned in (1) should be enough to pass an interview.

4. Refer back to the book and, when needed, read for deep detail to supplement your on-the-job learning.

5. Read the research papers if you want to get to the frontier. (Same as above.)

Step (4) of the new cycle is where the exercises would come in, but most people by that point are just trying to solve the problem at work.

While I haven't read the four you mention not having examples, in my experience, "conserving space" is the last thing most programming books do.

Reading this post, my first thought was "How do you read a programming book 3 times? They're so long?"

I actually feel like most programming-related books are artificially padded with unneeded content, just for the sake of making them longer. Perhaps so they'll seem more like they're worth their price?

In my opinion, too-long technical books are a problem. If you've only got an hour or two a day to read, it can take a week or two to get through a decent-sized technical book. Add in xentronium's point about lack of exercises, and I don't know how anyone is supposed to retain much knowledge from these books.

Providing small, challenging problems is a very valuable resource. I'm currently reading An Introduction to Programming in Java (as preparation for the Princeton Algorithms course on Coursera). While the book may not be the best Java book, each section has 40+ programming exercises. Sometimes the exercises are boring, but I do most of them anyway because they are in themselves a learning exercise.

First of all, there are a few main categories of exercises I encounter when I read:

1. exercises left to the reader 2. exercises with solutions

When I read a book, I typically dislike exercises left to the reader, especially because when I get to work on a solution, I have no idea whether it's any good at all, especially in a language-specific book where there's a good chance my solution is bad for not being familiar with the language -- not necessarily a lack of reasoning as much as familiarity.

SICP is one exception to this in my experience (I haven't read all the books in your list), because it's not language specific, and I'm reading it with the known mindset it will take months to go through. I'm not reading it to learn Scheme, but to learn to program, and in my opinion, there's a different mindset involved. Still, there were times where I wished I could get solutions without buying a separate manual. I ended up looking for solutions online and found many of them; this isn't an option with many new books, and shouldn't be expected as a feature.

For exercises with solutions, I like these a lot better to begin with. I can work on things until I fail, absorb the solution by reading it, and gaining experience. If you have plenty of exercises, the solutions will significantly increase the volume of the book, though. An online repository is a very decent solution, and even lets you add comments and explanations.

I want to focus on the idea of explanations. Exercises with flat solutions without any explanation of what is going on, just "it works" are something that somewhat annoys me. "Here's code, figure it out kiddo" is a valid approach and makes sure the reader that goes through it still understands a lot, but it doesn't mean the reader won't miss stuff.

If I take the typical quicksort example of functional languages and just say "Implement quicksort using language X" and show one solution, it's up to the reader to figure out whether it's optimal, demonstrative, etc. ("Why is it important to pick a pivot the way it was done?") If there are indications, then it's nice to know how the code works, but you don't always get to understand how to create such code on your own. You will tend to know why the code is the way it is, but not necessarily how to build similar though different code on your own -- there's a subtle distinction there.

This is where a lot of exercises fall short, in my opinion. It's more obvious in math books where only the final answer is given. You can validate your answer, but if you don't know how to come up with one, you're lost. Good luck, ask someone or go back until you're brilliant enough to do this exercise. If there are steps done, nothing tells the reader why that one was picked or why the author decided to attack from that angle instead of any other one. Personally, this would tend to get me into the area where I know how to solve the exercises in the book, but I'm quite unsure about how to solve those outside of it.

I do prefer the approach where the exercises are something you can be guided through. The author explains the design decisions and why things are the way they are. I found it's a format that made more sense to me when I was watching screencasts, or when working with a trainer (or as a trainer), teacher, or whatever. It's how I was taught sports, music, and so on. It might just be a result of how I personally learn better (a series of explanations why things are done the way they are, not just letting me speculate why), and different people tend to learn differently.

The downside of this approach is that it's significantly longer, and you'll have far fewer exercises available as a reader (time and space are limited resources).

That's the approach I tried to take with LYSE. I'm not saying I got it right, or that it's better than whatever other approaches that exist, but it's the one that made the most sense to me as an author, because it made sense to me as a learner. I like that I can be guided through examples, that the person teaching me tells me "here are the possible ways to do it. I picked this one because of reasons x, y, and z", as I feel I now know how to make similar decision on my own in the future when encountering similar problems.

First, I would love to include exercises, however two factors conspire(d) against us. First, some of our favorite C.S./programming books have amazing exercises, so we respect the art of creating interesting and relevant supplementary material. It is no small task to design a book that flows, teaches the right lessons and also provides a set of exercises.[1] If we were to include exercises we would think very hard about what to include and how it fits into the book as a whole.

Second, the schedule for our book was quite tight given that we both have families and full-time jobs. We could write the book in a satisfactory way on time, or we could include exercises. We chose to write the best book possible given our time and ability (or lack thereof). We actually did create some exercises, but felt it was not worth including a partial set. Maybe next time. However, all of the same considerations would apply.

As you'll notice, our exclusion had nothing to do with page count.

Great question.

[1]: I should say, "for us" since others seem to do it easily.

I think writing great exercises that teach and integrate with the text is really hard and many authors/publishers don't have the time or incentive to do so.

I also could never read a programming book from the start to the end. When I used the language a lot and used the book as reference, I read all the pages somewhen in a several months interval, and in some random order. When I didn't use the language a lot, I just didn't finish the book.

Nowadays the best reference is online, so while books are still good for giving me a start, there is a long time that I don't finish one.

At first I open the ToC and go read the few stuff I do absolutely want to read about and "can't wait" to read.

Then I force myself to read the entire book like a novel at least once.

One of the great thing about reading it at least once is that once a while you'll read something you don't really think you'd need right away or that won't necessarily "click through" but, later on, you'll remember "seeing it somewhere in the book". And bam, you take the book's ToC or index and find back what you're after.

I've done it countless time with "Java Concurrency in Practice" for example. At first I read what I wanted to read the most. Then I read like a novel. Then now I use it as a "reference".

(most of the book, just like most Java books, can be dumped to trash now that I'm working with a language using lockless concurrency but that is another topic ; )

First, pick up a shit-ton of books. Or o'reilly safari. Use it to quickly scan for good tools, in combination with GitHub.

Then, index the book. That is, read the most relevant chapters lightly, but read the source code closely. Make sure all the source makes sense. If it does, you're in great shape. If not, either the author is poor or you've gotta page-in back references.

Then, start hacking together code. Page-fault on the book (and others like it, including example source).

I often choose a random language for solving a small problem, so that I can learn it. It's often not the best language for the problem, but it shows what the language is good for.

For me a monolithic resource is great for getting started in a language, but most books are too deep, so I normaly don't finish them.

I'm only half-joking here... It's a semi-serious question!

[1] http://psychcentral.com/blog/archives/2010/09/03/8-tips-for-...