Live data from Hacker News

Ask HN: How do you read programming books?

news.ycombinator.com

21–30 of 84 posts

Re: Ask HN: How do you read programming books?

#21
post #8

I learn something first by using it, applying tidbits from blogs, online tutorials, Stack Overflow and just trying to figure out how to get it to do what I want. 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 t…

I agree with this approach. My experience has been that having a primitive mental framework in place really helps with retention (and interest) when you're doing in-depth reading on a topic (which you probably are if you're reading a book). Start superficial, mess around, and then things not only make more sense, but are also more exciting and easier to remember, when you really dive in.

Re: Ask HN: How do you read programming books?

#22
I've almost never used books to learn programming. I read a bit of SICP a few times but lost interest. Otherwise all I do is just follow whatever "x guide/tutorial/introduction" I find on google, or the language's official documentation if it serves as a good learning resource, like for Python and Microsoft properties.

Re: Ask HN: How do you read programming books?

#23
I've heard studying "sinks in" when you're recalling what you learned earlier. So I spread out the reading of the book, trying to remember the next day what I'd read the previous day (before checking in the book to see how well I've remembered it).

I've also heard people say that you have to learn by doing. So I try to play around with whatever I've learned from the book. Doing the examples is good, but dreaming up your own fun variations can be even better.

Someone once suggested that re-typing the examples is actually really helpful too. Your whole brain is engaged -- fingers moving, keypads being chosen -- and whatever patterns there are in the language start to emerge.

I think the most important thing is just "be gentle with yourself." It's possible to push too hard to learn something big and complicated all at once. It wouldn't hurt to Google up a few online discussions, just to get a little extra context for what you're reading in the book -- and a supportive community.

Re: Ask HN: How do you read programming books?

#24
I've never actually gotten through an entire programming book. I'm too hands on. I usually get to building stuff before the book is through. This is good and bad. I'm self-taught and I really want to get through this algorithms book, but I keep getting distracted.

Books are great but many times, they spend so much time on information that I don't need instead of the practical stuff.

Re: Ask HN: How do you read programming books?

#25
There are two kinds of programming books. Some are technical references covering a specific technology (usually a tool, library, or framework); I generally find these to have a short shelf-life and to be lower in quality. New versions of software can quickly result in their obsolescence, and sometimes the examples and precise details are not accurate even when published. However, I have found such books to be _essential_ when learning an emerging technology, where maybe there's API documentation but very little (or very poorly written) conceptual/overview documentation. Often the book's author is elbows-deep in the implementation of the technology and can explain some of the essential concepts. I typically buy these kinds of references only when I know I need to come up to speed on something, often a new fresh open source hell with its own jargon (looking at you, Angular), and then I make a dedicated attempt to power through the book and the examples. You can go broke if you buy this sort of book and don't put in the effort for an immediate return; also, you can skip whole chapters that aren't applicable to your situation.

The second kind of programming book covers a broader topic and/or more mature technology. They can vary from an academic orientation to almost a sly anti-intellectual style (e.g., the Camel Book). Here you learn core concepts that will be more-or-less evergreen. These are books you will want to read cover to cover and then return to again and again, for years in the future. These books vary in their tone, some serious, some silly, but they all should be fun to read due to the clarity of their prose and presentation of essential concepts. The ultimate example is TAOCP.

Re: Ask HN: How do you read programming books?

#26
post #17

Earlier quoted context omitted.

Head First book author here -- I wrote Head First C#, Head First PMP, and Head First Agile (and three other, non-Head First O'Reilly books) -- and I wanted to push back on your first point. We work really, really hard to include quality content. But I understand why people sometimes make the point that you made; I did the same thing myself at first. It's easy to dismiss one of our Head First books as less-than-seriou…

>There are a lot of pictures. [...] highly visual format, Thank you for your response. To clarify, I'm not an elitist that rejects cartoons and informal style. For example, I think the "Calculus for Dummies" [1] with the cartoons is a good math book. I'm also not really not talking about the visual "clutter" that others complain about either. Cartoons are fine but I prefer that the drawings/illustrations really impar…

>Similar to cartoons, I have similar complaints about "conversational style" that many authors think helps with pedagogy but it really doesn't. (You can explain things terribly while using a conversational tone, and likewise, explain things clearly without a serious tone.) I'll save that criticism of that for another essay.

If "you can explain things terribly while using a conversational tone, and likewise, explain things clearly without a serious tone", then does it not suggest the tone is not a good signal for quality?

David Griffith's Intro to EM book is written in conversational style. And is by far the best book I've seen on introductory EM (and I've read a bunch).

Re: Ask HN: How do you read programming books?

#27

There are two kinds of programming books. Some are technical references covering a specific technology (usually a tool, library, or framework); I generally find these to have a short shelf-life and to be lower in quality. New versions of software can quickly result in their obsolescence, and sometimes the examples and precise details are not accurate even when published. However, I have found such books to be _essent…

Spot on ; we might need a name for this second category of books ("technology-agnostic"?).

These are the books I want to search for in a bookstore ... without getting polluted by the unlimited variations of "Teach Yourself in 7 days" or "Learn with ".

Re: Ask HN: How do you read programming books?

#28
For learning a new language, if I have enough time, I read through the entire book. This helps me learn the terminology and names for concepts. It's much easier to search for more information when you know the right jargon. Reading everything helps to gauge the scope of the language and map it to or from known concepts. This is how I read TC++PL and Ada as a Second Language, which I think worked because their of their breadth.

Sometimes there's not enough time to do that, like when you're thrown into an unfamiliar code base or need to interface with a new API. Then I thoroughly read enough chapters to get the syntax and skim the start of other chapters, plus the index/glossary, again minly to learn terms. The required depth depends on what you're doing. If there's an unfamiliar concept heavily used in the code, of course read those sections more.

I usually avoid exercises because I already have a project or goal, so I work up my own examples that advance those needs but still use the idea or technique of the exercises. I highly recommend trying out a new technique with a small test before applying it at large, or assuming its use as part of the software architecture. You don't want to discover late in the game that the way you planned to use Java generics or C# Pinvoke won't work.

Sometimes the goal is to learn a new technique or dive deeper into the language. I've immensely enjoyed books by Meyers, Alexandrescu, and Sutter, that have more self-contained sections. I still find it useful to read the ToC or skim the chapter introductions, but my mindset is usually more "how can I apply this?", and reading everything straight through doesn't give me enough time to focus on specific things.

Re: Ask HN: How do you read programming books?

#29
If the book is documentation, I only read as needed.

> Do you read it in one go and later try examples or go through entire book by trying all examples?

I do a few of the examples until I learn and figure out how the works. I won't be doing all the examples, if they're just teaching the syntax or simply showing stuff that can be found at the documentation like functions parameters.

> Do you read the entire book or just the part to get the job done?

I only read the whole book if I'm completely naive and want to deeply learn about the . I usually jumps chapters which have content I've used before and is not difficult to me.

> What methods/techniques have you found useful while reading such books?

Write your own cheatsheet or take notes as you go. Also use the official documentation for functions definitions and similar stuff.

Re: Ask HN: How do you read programming books?

#30
post #26
post #17

Earlier quoted context omitted.

>There are a lot of pictures. [...] highly visual format, Thank you for your response. To clarify, I'm not an elitist that rejects cartoons and informal style. For example, I think the "Calculus for Dummies" [1] with the cartoons is a good math book. I'm also not really not talking about the visual "clutter" that others complain about either. Cartoons are fine but I prefer that the drawings/illustrations really impar…

>Similar to cartoons, I have similar complaints about "conversational style" that many authors think helps with pedagogy but it really doesn't. (You can explain things terribly while using a conversational tone, and likewise, explain things clearly without a serious tone.) I'll save that criticism of that for another essay. If "you can explain things terribly while using a conversational tone, and likewise, explain t…

>, then does it not suggest the tone is not a good signal for quality?

You highlighted my spelling mistake and I updated the post to correct it. My examples were meant to be opposites.

There are many bad books out there with a conversational style. There are good ones too. The problem is that readers are mislead by the easy-going tone of the first few pages and therefore lulled into thinking it's a quality book because of its chattiness and informality.

Likewise, many authors writing in a conversational style think they wrote an easy-to-understand book because it's conversational. That cause & effect isn't true. One can write a beginner book that has clear teaching with or without a conversational style.

Post reply on HN