How I Read Programming Books

&#60;rant&#62;<p>For reasons unknown to me, intro-level books for programming languages stopped including exercises. K&#38;R had exercises, SICP had exercises, Dragon Book had exercises. Clojure in Action, Clojure programming, Joy of Clojure, Programming Erlang — none of those have any. What happened? Are they trying to conserve space?<p>&#60;/rant&#62;

The "typing code out" is important. A lot of us learned just this way in the early 80s, because that was the only way we could get the source: buy a magazine or a book that taught, say, game programming in BASIC, and then type in code. The inevitable syntax errors made you spend time going back through to figure out what you did wrong, not to mention the time you spent actually looking at each line.<p>Downloading the code from a book's web site has nowhere near the same effect, even if it "feels" more efficient.

I think I'm too ADD for this. Here's how I read programming books:<p>1. Open Table of Contents and find topic I'm interested in. 2. Open page of topic. Read about it. Start coding along. 3. Close book.<p>I feel like I can't really read them any other way. I haven't read one cover to cover in years, and that was when I was doing tech editing for publishers and I had to read the whole thing.<p>Am I alone? Do most of you read the whole thing like a novel?

I'm more or less the opposite of the author: I find a problem first, pick the language that seems most suitable or I think I can code fastest in, and have at it. Advantages:<p>- Write interesting code right away, which helps me focus - No need for a monolithic resource like a book, just Google the specific problem to be solved - Solve a problem while learning<p>The biggest downside is that I don't tend to write idiomatic code: when you hack away at your own projects, they all look like your style, regardless of the source language. It took me several months to pick up good C practices at my new job, and I'm still not proficient at Ruby, Python or Java, despite having written plenty of code.<p>To try and combat this problem, I've started reading more advanced documents and talks in languages where I think I've got an OK base understanding. These tend to be more interesting, and better demonstrate the strengths of a given language.

For anyone reading to acquire knowledge, or to learn new things, may I recommend How To Read A Book by Charles Van Doren, Mortimer Adler.

At this late stage in the game, learning a new language for me is a matter of deciding on a project and building it while keeping some appropriate reference at hand. If I read a book linearly at all it's to read just enough to get the "Hello, World" going.<p>BTW, it doesn't take very long to become usefully productive in a language. When I hire developers who've never worked with a language before I budget 6 weeks for them to start being productive and 6 months until they're truly proficient.<p>Because of that, I place a higher premium on their raw talent and level of interest in the platform and type of work we have than on the particular stack they're already familiar with.

This approach really depends on the brevity of the programming books you are reading. I can't see someone leafing through CLRS, then again, then once more shortly afterwards. Or other algorithm books like Algorithms in C, or e.g. SICP or How To Design Programs. I read programming books at a glacial pace, and sometimes I find it very tough going. So tough that I would not be in a hurry to repeat the process, so I take notes. Also I find the desire to read another different book much greater than the desire to retread the same material.

3 full reads of a book? That's highly inefficient, and it probably becomes very boring (at least for me -- but that might be my ADHD).

That's very interesting. I usually read once, sometimes don't even write code but I fully understand and ready to use the language. Maybe it's about the programming expertise level you already have. Of course, when reading stuff like Haskell, Scala you need to practice but when reading Python, Java... not for me.

My programming II professor would always tell us to step away from the keyboard/monitor, and physically write out a source file x times to help learn a language. There is definitely something to this process that helps language syntax piece itself together in the brain. Probably because it's similar to the process we use to practice writing and reading our human languages.

I strongly agree with the author.<p>The first read is like a novel. You want to know the plot, the main events, and not much else.<p>The second read is as though you're going to write a report. Paying specific attention to detail, noting unique and important bits.<p>The last read through is the nitty gritty. You have notes and the flow in perspective. Now you're putting it to real use.

"Do the exercises" is only something you can do if you have the book. Learning from blog tutorials don't usually have that benefit. You could still use this person's approach but you'd have to substitute in something for step 3. I'd say some kind of "mini-project" makes an acceptable substitute in most cases.

This is pretty much how I use them as well, but I also intersperse personal projects in between using what I've learnt and trying to acquire new information as well. It's effective for me, I seem to retain more information this way rather than going for one pass through a book.

The strategy that works for me is:<p>- read the book and write down the key points (usually a full book will be reduced to around 10 pages)<p>- read the notes, and try to do the examples<p>- rework the examples a second time, refer book and notes

Nice that the author has read so many programming books so that creating an algorithm for reading such books is cost-effective.

One thing I've learned: do the excercises. Just do them.

Been reading in <a href="http://antijingoist.github.com/AlphaSymbolic/" rel="nofollow">http://antijingoist.github.com/AlphaSymbolic/</a>.<p>I'm not exactly sure what the best strategy is for applying AS to programming languages since it has no "uppercase" glyphs.