Ask HN: How do you read your programming books?

https://news.ycombinator.com/item?id=9515910

by atmosx • 11 years ago

12 5 11 years ago

news.ycombinator.com

Hello HNers,

When you buy a new programming book, how do you read it? More specifically:

* Do you write the code or just 'compile it on your mind' and go?

* Do you re-read the same chapter over and over again if you feel that you missed something, or you go forward even if you feel something is missing?

* Do you do all the exercises listed at the end of every chapter (this doesn't apply to every book, but most programming books do have exercises)

I'm curious, because usually by 50% of the book I feel that I can do everything I wanna do and my attention drops. I just wanna start my project using book's X framework/language.

ps. I'm generally speaking a slow reader. I've come to the conclusion that I literally read 'slow' and it bothers me speeding up my natural reading rhythm but it also bothers me the fact that my GF usually finished the page/article while I'm still in the middle. On the positive note, I read much more carefully most of the times. I've seen people here stating that they read Flanagan's JS book in 5 days... Which to me seems kinda impossible (if you have no prior DEEP knowledge of JS and OO programming).

Regards :-)

rvalue• 11 years ago

I transform every chapter to some piece of code, either one already in it or of my own. If the chapter is only explaining the fundamentals of something, i make separate yellow notes in my study for a quick concept look.

If I don't understand something at all, i usually search for code samples in Github someone might have used or look for questions related to it on stack overflow. This gives me a general idea if what i am learning is complicated stuff, or considered difficult or unused or is complete bullshit.

At the end, I implement something by taking pieces from all chapters, & keep that project for later reference.

Also, when I am learning about something which is more of a framework, I try to find reasons of why something is done like that, look into internal implementations without getting into much complexity so that if ever this framework support goes off, I know how to implement my own smaller version atleast

I am a slow reader and I don't like any disturbances so I pick the best time to learn something, probably night time.

shmapf• 11 years ago

I empathise with you talking about the "natural reading rhythym", I'm a slow reader too, but like to think I also read more carefully than those who get through the pages faster.

In response to the questions:

1. For me, this depends on the subject matter. When its a new language I'm learning, there's no alternative to writing code. Languages can be very deep, and there is often a large amount of new content for your mind to overcome. Thus there are many places you can trip up when you wouldn't have anticipated it in your head. In these cases, I write code inline with reading about it.

When its about design, or a more high level subject, for example about testability, I don't usually write much code; the lessons learnt are more abstract. The code tends to require more work in these cases too, and I'm lazy. Having said that, my day job is software engineering, and combined with my side-projects there are plenty of opportunities to try out the new concepts I learn about in such resources - usually within the order of a week. This step is, in my opinion, vital. I believe you must put the concepts into practice at some point in order to truly feel comfortable with them, and the sooner the better while they are fresh in your mind.

2. I'm a first principles guy, so don't like building up knowledge on unknown foundations. I re-read until I understand it, and then advance. This of course assumes that the structure of the resource has been carefully considered, with few forward references. When the author declares that something specific will be explained in chapter X, I'm happy to take their word for it, but in the absence of such statements it makes for uncertainty. Thankfully, in my experience most authors I have read do take the time to add such assurances, so its possible to read in a continuous manner from start to finish.

3. In the past I have skipped the majority of these exercises. In this case psychology seems to be against us - we underestimate the unknown unknowns, so tasks seem simpler than they really are. For this reason I am actively trying to do the exercises properly these days. I tend to do the simple ones in my head, and the more complex ones in real code. The way I distinguish between simple and complex is "Can I write out the exact syntax of the solution in my head start to finish?".

elevensies• 11 years ago

Usually I read more normally, or just look up things that I'm interested in, but I have a different style when I want to "force-read" something unfamiliar. For each chapter:

1. Read chapter subtitles subsubtitles, etc, and the summary if there is one at the beginning or end.

2. Go thru the chapter reading the first sentence of each subsection

3. Again, reading the first sentece of each paragraph

4. Again, reading everything

And for bookmarking and hilighting I have 4 categories: important, interesting, unanswered question, reference.

And if I have goals for reading, I write them on the back few pages and fill in information as I find it.

I usually do this on paper, I still find it kind of awkward to do in the Preview app or whatever, and it is not possible for me on a phone.

likeclockwork• 11 years ago

I like 3 different kinds of programming literature for different reasons and approach them differently.

1. Dense reference material. I read this cover to cover, because every time I read it I am guaranteed to learn something because it's more than I could ever hope to learn at once.

2. Theoretical CS texts (and programming philosophy/methodology). I follow along if it makes sense to, on paper or with whatever programming language seems like the best fit.

3. Examples/Tutorials I skim these, since I'll just cherry pick them for the concepts I need/want to know. I might read in depth for understanding of a tricky portion or extract something clever and play with it.. but finding the right examples is so hard that I tend to look at a lot of examples and not spend too much time on thought that don't meet a threshold.

So when I approach a book or other guided learning material, I'll read cover to cover to get an overview of something but I'll apply each of the 3 modes above to its various types of content.

Good dense reference material is like gold though. I read as much of it as I can. I wish I could find more of it for things I'm interested in that isn't the f@#!ing source, because that takes longer to read from end to end. Specs, API references, generated docs.. you're guaranteed to learn something.

shortoncash• 11 years ago

I don't think it's practical to read a technical book from cover to cover. There's just too much to learn and it's too easy to forget everything you've read if you don't immediately apply it right away.

I tend to read to find what I want to know. When something I tried in the real world breaks, I come back. If my concoction continues to not work, I come back. Eventually the book gets finished.

I do the same thing for math books. You have to play with the concepts for them to stick. In college, it was always hard to play with things because of time constraints and having to get to the next exam. Outside of college, if you're not time constrained, there's no reason you shouldn't be screwing around with every concept that's shown on the page.

Ask HN: How do you read your programming books?

Related Stories