Ask HN: How do you read programming books?
83 comments
I'm going to give away the secret of autodidactic learning here. I developed this technique in college. Although there was no such thing as YouTube back then, iTunes etc.
I get at least two, preferably three data sources on the same subject. Read them all in Parallel and take notes. Getting multiple perspectives is critical.
What works for me is two well-made textbooks and a Youtube series, iTunes university, etc course.
““In almost all textbooks, even the best, this principle is presented so that it is impossible to understand.” (K. Jacobi, Lectures on Dynamics, 1842-1843). I have not chosen to break with tradition.”
–V. I. Arnold, Mathematical Methods of Classical Mechanics [5], footnote, p. 246
I get at least two, preferably three data sources on the same subject. Read them all in Parallel and take notes. Getting multiple perspectives is critical.
What works for me is two well-made textbooks and a Youtube series, iTunes university, etc course.
““In almost all textbooks, even the best, this principle is presented so that it is impossible to understand.” (K. Jacobi, Lectures on Dynamics, 1842-1843). I have not chosen to break with tradition.”
–V. I. Arnold, Mathematical Methods of Classical Mechanics [5], footnote, p. 246
Exactly how I aced high school. And got into MIT.
Much less useful to me in college. Even less useful now. I must have 100 programming books in Google drive.
The only way to learn something (and certainly programming) at a high level is to force yourself to write down a well- defined, closed-end problem, and then sit down and solve the motherf_____r. You learn what you need to learn, build, and invent along the way, and that survives longer than the original problem.
The only way to learn something (and certainly programming) at a high level is to force yourself to write down a well- defined, closed-end problem, and then sit down and solve the motherf_____r. You learn what you need to learn, build, and invent along the way, and that survives longer than the original problem.
Right. I think learning this way forces yourself to solve the problem by teaching the discipline to yourself. It's always said that you don't truly understand something until you are able to teach it to another so in that sense you a sort of "tricking" yourself into teaching it to yourself as you learn it. It's a round about way of thinking / doing things but those mental gymnastics feel necessary to me to absorb such unnatural and abstract (to me) topics.
>The only way to learn something (and certainly programming) at a high level is to force yourself to write down a well- defined, closed-end problem, and then sit down and solve the motherf_____r. You learn what you need to learn, build, and invent along the way, and that survives longer than the original problem.
This is how I've been successful as a self-taught developer.
This is how I've been successful as a self-taught developer.
I tried this technique with C++ but soon I realized it was a dead end. You try to build anything with C++ without some inner understanding of concepts like const, templates and STL, and I can bet things will blow up pretty fast.
This is how I learned most of my mathematics before highschool. I just made up a problem such as calculating the angle which minimizes the time to intercept a slowing
rocket which taught me a lot about differentiation.
However, I didn't become amazingly successful in life.
However, I didn't become amazingly successful in life.
I Agree. You learn so much more when you are focused on solving that problem.
Can you tell which ones? ("100 programming books in drive ")
+1 for multiple sources. I've yet to find a single source that is clear and understandable across the board. Switch between sources when a topic seems to be unusually difficult to understand. Then go back to your original, favorite source.
Note that I do not think this applies to books that simply showcase and act as a more advanced reference of programming languages. Those are normally plain enough, I think.
For others subjects, like math or CS, multiple sources have always proven invaluable for me.
Note that I do not think this applies to books that simply showcase and act as a more advanced reference of programming languages. Those are normally plain enough, I think.
For others subjects, like math or CS, multiple sources have always proven invaluable for me.
It's a tough choice to follow sometimes. I know very very well that different perspective makes a world of difference (one book left me dry for 10 years, another unlocked me in a week). But it's hard sometimes to keep progress on many fronts.
I still second your system. Makes me wanna try.
I still second your system. Makes me wanna try.
Can attest.
Learning a music instrument right now, and a combination of youtube, guitar instruction books, and earing music off my music player seems to be the strategy that makes the most gains. That and spaced repetition (5 1-hour practices sessions is better than 1 5-hour practice session)
Learning a music instrument right now, and a combination of youtube, guitar instruction books, and earing music off my music player seems to be the strategy that makes the most gains. That and spaced repetition (5 1-hour practices sessions is better than 1 5-hour practice session)
1) Make sure you're reading a quality book. Sturgeon's Law[1] is true -- 90% of everything is crap including programming books. Check amazon reviews, forum recommendations for consensus of quality books. (E.g. many of OReilly "Head First" series of books have cute cartoons but they actually don't have quality content.)
2) Most programming authors do not write about tradeoffs. They write about language syntax or library features and end up being (inadvertent) evangelists. All languages have warts and problems that books don't talk about. To supplement book reading with a dose of real-world realities, always corroborate with forum discussions, stackoverflow, etc.
3) Instead of reading 1 book, go through 2 in parallel from different authors. E.g. read about monads chapter in 1 book and find the same topic in another book. Different authors explain concepts in different ways which can help reinforce the learning
[1] https://en.wikipedia.org/wiki/Sturgeon%27s_law
2) Most programming authors do not write about tradeoffs. They write about language syntax or library features and end up being (inadvertent) evangelists. All languages have warts and problems that books don't talk about. To supplement book reading with a dose of real-world realities, always corroborate with forum discussions, stackoverflow, etc.
3) Instead of reading 1 book, go through 2 in parallel from different authors. E.g. read about monads chapter in 1 book and find the same topic in another book. Different authors explain concepts in different ways which can help reinforce the learning
[1] https://en.wikipedia.org/wiki/Sturgeon%27s_law
Completely disagree on the "Headfirst books" comment.
All the head first books I have read (Java, Design Patterns, Android, C, Ruby) have very high quality content. I have read great books on all these subjects along HFs. i.e. The Design Patterns Smalltalk Companion, K&R, etc. The HF books really help visualize and actually enjoy the subjects, they also have great exercises that help to cement the concepts one has just learned. If any of the HF authors read this, thanks for these books, they have help us a great deal.
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-serious if you're not used to the format. There are a lot of pictures. There's a LOT of whitespace. There's redundancy; we'll say the same thing more than once. And most of all, when we do our job right they're not boring -- which, to many people, reads as non-serious. But we find that when people approach Head First books with an open mind, they find that it's actually a really effective way to get a lot of information into your brain quickly and easily.
We also know that while a lot of people love the informal and highly visual format, some people just can't stand it. There are some people who just want a dense, concise, terse book that they can absorb all at once. Readers like that just won't like Head First books. That's why every Head First book starts with an introduction that says who the book is for and who it's not for. Coincidentally, my coauthor, Jenny Greene, and I just did an interview on Dave Prior's "Drunken PM" podcast, and the first question he asks us is about this "Who this book isn't for" section: https://www.projectmanagement.com/blog-post/34188/Head-First...
Short, shameful confession: I had a similar reaction to yours when I first saw Head First Design Patterns; I dismissed it out of hand, ostensibly because there were some less-common design patterns from GoF that it didn't cover, but really because I just didn't "get" the format. A year later, when our editor at O'Reilly floated the idea of writing Head First PMP, I went back to it and really read it, this time with a much more open mind (for example, I actually did all of the code exercises instead of just reading them). I realized why I'd made my earlier mistake in dismissing the book -- and gained a lot of respect for how much work Eric Freeman, Elisabeth Robson, Kathy Sierra, and Burt Bates had put into it. They were really careful about what they chose to cover, and covered those topics really thoroughly. They give you several different chances to "get" each concept, showing it to you from different angles so that you really absorb the full context. They put a lot of care into managing the pace of the book so it's a steady stream of learning and not a flood. They repeated things that needed repeating. And it all works. Really, really well.
I thought I'd understood design patterns pretty well before I really read Head First Design Patterns. afterwards, I was actually better at using them in code in real life. When I'm not writing books or training teams, I'm writing code both professionally with teams and as outside of work. The incredible quality of the content in their book helped me understand design patterns better.
Jenny and I strive to bring the same care to our Head First books. I think we've done a pretty good job of including quality content that's worth our readers' time; I hope they agree.
It's easy to dismiss one of our Head First books as less-than-serious if you're not used to the format. There are a lot of pictures. There's a LOT of whitespace. There's redundancy; we'll say the same thing more than once. And most of all, when we do our job right they're not boring -- which, to many people, reads as non-serious. But we find that when people approach Head First books with an open mind, they find that it's actually a really effective way to get a lot of information into your brain quickly and easily.
We also know that while a lot of people love the informal and highly visual format, some people just can't stand it. There are some people who just want a dense, concise, terse book that they can absorb all at once. Readers like that just won't like Head First books. That's why every Head First book starts with an introduction that says who the book is for and who it's not for. Coincidentally, my coauthor, Jenny Greene, and I just did an interview on Dave Prior's "Drunken PM" podcast, and the first question he asks us is about this "Who this book isn't for" section: https://www.projectmanagement.com/blog-post/34188/Head-First...
Short, shameful confession: I had a similar reaction to yours when I first saw Head First Design Patterns; I dismissed it out of hand, ostensibly because there were some less-common design patterns from GoF that it didn't cover, but really because I just didn't "get" the format. A year later, when our editor at O'Reilly floated the idea of writing Head First PMP, I went back to it and really read it, this time with a much more open mind (for example, I actually did all of the code exercises instead of just reading them). I realized why I'd made my earlier mistake in dismissing the book -- and gained a lot of respect for how much work Eric Freeman, Elisabeth Robson, Kathy Sierra, and Burt Bates had put into it. They were really careful about what they chose to cover, and covered those topics really thoroughly. They give you several different chances to "get" each concept, showing it to you from different angles so that you really absorb the full context. They put a lot of care into managing the pace of the book so it's a steady stream of learning and not a flood. They repeated things that needed repeating. And it all works. Really, really well.
I thought I'd understood design patterns pretty well before I really read Head First Design Patterns. afterwards, I was actually better at using them in code in real life. When I'm not writing books or training teams, I'm writing code both professionally with teams and as outside of work. The incredible quality of the content in their book helped me understand design patterns better.
Jenny and I strive to bring the same care to our Head First books. I think we've done a pretty good job of including quality content that's worth our readers' time; I hope they agree.
Long time reader of Head First series here. I have finished :
- HF Software Development
- HF Design Pattern
- HF Java
- HF Android Development
I have no complaints. Really, thank you for making those books. They helped me a lot. I think you couldn't have every reader to agree that your book is good because each person has their own taste, but to be fair, yours do a good job in delivering quality content in many aspects under a friendly narrative.
Thank you! I've spent some time on the phone with several of the authors of those books. They did a great job with them.
If you get a chance, go to Amazon.com and leave a five-star review for each of those books. It seems like a small thing, but you'd be surprised about how each additional review with five stars helps, even a one-sentence review. They all definitely deserve it!
If you get a chance, go to Amazon.com and leave a five-star review for each of those books. It seems like a small thing, but you'd be surprised about how each additional review with five stars helps, even a one-sentence review. They all definitely deserve it!
Head First books were a great help back when I was starting with programming. I was a teenager and not as comfortable with English as I am now.
Books like Head First Java and Head First Web Design helped me a great deal. I don't know if I would read them as my first option nowadays, but they definitively have their use and are great at what they aim at.
Books like Head First Java and Head First Web Design helped me a great deal. I don't know if I would read them as my first option nowadays, but they definitively have their use and are great at what they aim at.
>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 impart knowledge or insight rather than "decorate" a book's page like wallpaper.
For example, I looked at "Head First Networking"[2]. Using Amazon's "Look inside" feature to browse some pages:
- page 1: the clipart of the man and woman and the thought bubbles do not reward the user with quality knowledge in relation to the space they take up
- page 19: the clipart of the tourist with the arrows and thought bubble does not actually teach a networking concept
My point is: just because a book has cartoons & unserious style doesn't mean it has good presentation of teaching. It might be a suboptimal book that just happened to use cartoons.
Another way to put it: Comics can be a very powerful way to illustrate concepts but their power is underutilized in the Head First books. The cartoons are often "jokes" instead of teaching.
>which, to many people, reads as non-serious
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 with a serious tone.) I'll save that criticism of that for another essay.
[1] https://www.amazon.com/Calculus-Dummies-Lifestyle-Mark-Ryan/...
[2] https://www.amazon.com/Head-First-Networking-Brain-Friendly-...
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 impart knowledge or insight rather than "decorate" a book's page like wallpaper.
For example, I looked at "Head First Networking"[2]. Using Amazon's "Look inside" feature to browse some pages:
- page 1: the clipart of the man and woman and the thought bubbles do not reward the user with quality knowledge in relation to the space they take up
- page 19: the clipart of the tourist with the arrows and thought bubble does not actually teach a networking concept
My point is: just because a book has cartoons & unserious style doesn't mean it has good presentation of teaching. It might be a suboptimal book that just happened to use cartoons.
Another way to put it: Comics can be a very powerful way to illustrate concepts but their power is underutilized in the Head First books. The cartoons are often "jokes" instead of teaching.
>which, to many people, reads as non-serious
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 with a serious tone.) I'll save that criticism of that for another essay.
[1] https://www.amazon.com/Calculus-Dummies-Lifestyle-Mark-Ryan/...
[2] https://www.amazon.com/Head-First-Networking-Brain-Friendly-...
>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).
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).
>, 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.
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.
> My point is: just because a book has cartoons & unserious style doesn't mean it has good presentation of teaching. It might be a suboptimal book that just happened to use cartoons.
I hope you're not implying that I don't have good presentation or don't teach well! I'd obviously disagree with that. And I definitely think that the Head First books mentioned by others in their responses do a great job with both.
But I notice that you said "suboptimal," and then made this point:
> - page 1: the clipart of the man and woman and the thought bubbles do not reward the user with quality knowledge in relation to the space they take up
I recommend against judging the "optimality" of a book based on the amount of information that it packs into the smallest amount of space. Maybe instead of the amount of space taken up by the teaching, consider using the amount of time and effort required by the reader. Pages are cheap, especially in an electronic medium. A page like the one you mentioned is really quick to read and absorb.
Also:
> - page 19: the clipart of the tourist with the arrows and thought bubble does not actually teach a networking concept
I haven't read Head First Networking, and I don't know the authors, Al Anderson or Ryan Benedetti. But from a quick read, it's clear that that picture is part of a larger story (in this case, about tourists and an airline) that the authors are using as a teaching tool. Stories are a very effective teaching tool.
This should make sense if you think about it. Think about the last textbook that you read. Can you remember the major points that it made, in order? You might be able to, but most people probably can't do it accurately. Now think about the last movie you watched. It's much more likely that you can remember most or all of the major plot points and in the right order, because they're part of a consistent story.
Our brains are wired to remember stories, just like they're wired to remember places, faces, and emotions. The Head First books use stories to take advantage of this effect, not dissimilar to how people use memory palaces (https://news.ycombinator.com/item?id=2395739) to improve their recall.
Yes, telling stories (especially visually) takes a lot of page space. But readers absorb them quickly -- in my experience, it's a very efficient and effective way of teaching. The Head First books that I've read (and hopefully the ones that I've written!) do a great job of that.
I hope you're not implying that I don't have good presentation or don't teach well! I'd obviously disagree with that. And I definitely think that the Head First books mentioned by others in their responses do a great job with both.
But I notice that you said "suboptimal," and then made this point:
> - page 1: the clipart of the man and woman and the thought bubbles do not reward the user with quality knowledge in relation to the space they take up
I recommend against judging the "optimality" of a book based on the amount of information that it packs into the smallest amount of space. Maybe instead of the amount of space taken up by the teaching, consider using the amount of time and effort required by the reader. Pages are cheap, especially in an electronic medium. A page like the one you mentioned is really quick to read and absorb.
Also:
> - page 19: the clipart of the tourist with the arrows and thought bubble does not actually teach a networking concept
I haven't read Head First Networking, and I don't know the authors, Al Anderson or Ryan Benedetti. But from a quick read, it's clear that that picture is part of a larger story (in this case, about tourists and an airline) that the authors are using as a teaching tool. Stories are a very effective teaching tool.
This should make sense if you think about it. Think about the last textbook that you read. Can you remember the major points that it made, in order? You might be able to, but most people probably can't do it accurately. Now think about the last movie you watched. It's much more likely that you can remember most or all of the major plot points and in the right order, because they're part of a consistent story.
Our brains are wired to remember stories, just like they're wired to remember places, faces, and emotions. The Head First books use stories to take advantage of this effect, not dissimilar to how people use memory palaces (https://news.ycombinator.com/item?id=2395739) to improve their recall.
Yes, telling stories (especially visually) takes a lot of page space. But readers absorb them quickly -- in my experience, it's a very efficient and effective way of teaching. The Head First books that I've read (and hopefully the ones that I've written!) do a great job of that.
My first contact with programming at all was through Head First C#! :) Thanks for that! Although I ended up becoming a front-end web developer, it was a great first contact!
It's so gratifying to get that kind of feedback. Thank you so much! That is exactly why I write! :)
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.
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.
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 <SomeShortLivedTechnology> in 7 days" or "Learn <SomeUsefulTechnique> with <SomeBloatedFramework>".
These are the books I want to search for in a bookstore ... without getting polluted by the unlimited variations of "Teach Yourself <SomeShortLivedTechnology> in 7 days" or "Learn <SomeUsefulTechnique> with <SomeBloatedFramework>".
Well, I'm not sure I'd say "technology agnostic". I would include Programming Perl or Stroustrup's The C++ Programming Language in the second category. Parts of both are now dated, the accidental noise of APIs and so on, but the essential concepts are explained so fundamentally that you'd have no problem adapting to current APIs.
Sometimes, though, you just really need help coming up to speed on a bunch of accidental syntax and incantations to get the job done.
Sometimes, though, you just really need help coming up to speed on a bunch of accidental syntax and incantations to get the job done.
[deleted]
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.
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.
Did you take "Learning How to Learn" by Barbara Oakley?
To this I'd add writing questions as you go through each chapter, then after finishing the chapter, answer the questions you come up with in as much detail as possible. This also helps force recall (and is supported by some cognitive psych studies) and, by doing so, memory consolidation. When I was TA'ing in grad school, this is a method I'd show my struggling students, and it almost invariably helped their grades.
Build a mental map of where to find things, and then refer back for details as needed:
1. Skim the whole book. The goal here is to learn basic concepts, keywords, and the structure of the book.
2. Start coding, refer back to the book as I encounter things I don't understand.
This works better with paper books, because it's easier to remember where I saw something ("upper corner of left-hand page next to diagram, towards the end of chapter 10").
1. Skim the whole book. The goal here is to learn basic concepts, keywords, and the structure of the book.
2. Start coding, refer back to the book as I encounter things I don't understand.
This works better with paper books, because it's easier to remember where I saw something ("upper corner of left-hand page next to diagram, towards the end of chapter 10").
Most books I've read for a long time now start with an overview of the book's chapters in the introduction. Particularly advanced books will even tell you which chapters are prerequisites for others, and which ones you can skip for specific topics.
More on skimming:
Start with table of contents (topology) then index (vocabulary) if present.
Read summary of each chapter, starting at back of the book, working to front of book.
Based on that survey, deep dive into new/interesting (to you!) chapters in order of priority. Reference earlier chapters as needed.
Start with table of contents (topology) then index (vocabulary) if present.
Read summary of each chapter, starting at back of the book, working to front of book.
Based on that survey, deep dive into new/interesting (to you!) chapters in order of priority. Reference earlier chapters as needed.
OT: The book "How to read a book" drives home the importance of skimming a book and how to do it well.
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 things.
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 things.
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.
This technique also makes you unlearn incorrect aspects _a posteriori_, which can help reinforce good patterns. +1.
Lately I've been just reading and reading and reading without actually trying any coding. Mainly I've been reading about functional programming, languages I haven't used before, etc. The way I got into programming was through constantly trying to build things, without much formal education. I think once you have a certain amount of real word experience it's important to sometimes take a step back and just try to learn about new things without the distraction or pressure of trying to build something right away. This all depends on a person's point in their career and goals though of course.
I'm in sort of the same place, I'm in a reading frenzy to build up a vocabulary and learn category theory, functional concepts, etc.. While this is good I know I ought to spend some time practicing algorithms or building toys to really make what I'm learning intuitive.
I treat programming as a language. You understand it by going in hard and not trying to understand. If you learn it by trying to dictionary lookup every word, it's really slow.
Instead, you try to understand the context of a sentence, and then the words back from there.
So what I do is I read the table of contents and intro. Intro usually covers what makes the book different and has instructions on how to use it.
You'll find a few pillars. Like if you're reading an algorithm book you'll see Big O notation mentioned a few times. Focus on those pillars. Spend more time on them.
Maybe from Big O, it will give binary search as an example. Then skim the chapter on binary search and return to Big O until you master it.
You'll transverse the more important parts of the book better this way. Many books are not strictly meant to be linear.
I also recommend transversing content in this way as fast as possible once, in one go. Set aside about an hour to skim the entire book.
You'll get the "skeleton" of the book, what holds it together.
Then you focus on the pillars of the book. And once you're done with that, you can do the rest of the content you skipped.
Once you read something, explain it to yourself differently to prove you've mastered the concept. This might involve doing an exercise on it. If you're familiar with it, just drawing a figure might be good enough.
Also I agree with what the others have said: compare with other books on the topic and make sure it's a good one before you read anything.
Instead, you try to understand the context of a sentence, and then the words back from there.
So what I do is I read the table of contents and intro. Intro usually covers what makes the book different and has instructions on how to use it.
You'll find a few pillars. Like if you're reading an algorithm book you'll see Big O notation mentioned a few times. Focus on those pillars. Spend more time on them.
Maybe from Big O, it will give binary search as an example. Then skim the chapter on binary search and return to Big O until you master it.
You'll transverse the more important parts of the book better this way. Many books are not strictly meant to be linear.
I also recommend transversing content in this way as fast as possible once, in one go. Set aside about an hour to skim the entire book.
You'll get the "skeleton" of the book, what holds it together.
Then you focus on the pillars of the book. And once you're done with that, you can do the rest of the content you skipped.
Once you read something, explain it to yourself differently to prove you've mastered the concept. This might involve doing an exercise on it. If you're familiar with it, just drawing a figure might be good enough.
Also I agree with what the others have said: compare with other books on the topic and make sure it's a good one before you read anything.
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.
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.
I read a mess of these books. I subscribe to the Safari service put out by Tim O'Reilly and his krewe.
I look at the table of contents carefully.
I then read the whole book quickly to get oriented. At that point I make a judgement whether it's worth more time and effort.
Still here? Then I reread any chapters that relate to performance, because those chapters usually give a clear view of interesting issues in the subject system.
Then I do one or two of the problems / examples / demos. I do my best to avoid downloading and running them; rather I take the time to type them over; it helps me cognitively to understand what I'm doing.
Then I evaluate whether the material I'm learning will help me solve current problems, or give me ideas about solving future problems, or not.
I put the book in my Safari queue if it's relevant to either current or future problems. Then I go use what I've learned.
I wish I could say I wrote a quick personal review of every book. But I don't.
This works pretty well for me. Safari is a great way to read tons of books, because, well, "tons of books." They don't take up shelf space or have to be moved, or recycled if they turn out not to be useful.
I look at the table of contents carefully.
I then read the whole book quickly to get oriented. At that point I make a judgement whether it's worth more time and effort.
Still here? Then I reread any chapters that relate to performance, because those chapters usually give a clear view of interesting issues in the subject system.
Then I do one or two of the problems / examples / demos. I do my best to avoid downloading and running them; rather I take the time to type them over; it helps me cognitively to understand what I'm doing.
Then I evaluate whether the material I'm learning will help me solve current problems, or give me ideas about solving future problems, or not.
I put the book in my Safari queue if it's relevant to either current or future problems. Then I go use what I've learned.
I wish I could say I wrote a quick personal review of every book. But I don't.
This works pretty well for me. Safari is a great way to read tons of books, because, well, "tons of books." They don't take up shelf space or have to be moved, or recycled if they turn out not to be useful.
I will read the first few chapters to learn the basic knowledge. In the meantime, I will try my best to understand every example and run it. And then I will do something interesting such as writing a more complex program. Practice is my motivation to learn advanced topics. If I only read the book, I will lose interest quickly because this is very boring, especially for some difficult chapters.
After I think I have mastered the basic chapters, I will continue reading the subsequent contents. I won't try to understand everything in the advanced parts. Instead, I just read some useful content and treat other content as a technical dictionary so I can refer to it in the future.
I like learning a language/tool as quickly as possible, and then try to use it more skilled.
After I think I have mastered the basic chapters, I will continue reading the subsequent contents. I won't try to understand everything in the advanced parts. Instead, I just read some useful content and treat other content as a technical dictionary so I can refer to it in the future.
I like learning a language/tool as quickly as possible, and then try to use it more skilled.
With a beer in one hand and a shotgun in the other.
Typically I read the book a chapter or 2 at a time mattering how much information it covers. Mattering how technical it is I will write down every word I either don't know or second guess.
I will read over the code examples fully. At the end of the chapter I will try to recall the code example in my head, and see if I can replicate it. Mattering how good or bad that goes I will then move on or write the code out.
I keep notes the entire time I am reading. It helps keep me focus on the subject matter. My mind loves to wonder to much, and I have to beat it like a alien from the fourth dimension.
Also the notes act as long term reference as well I can review them every night for roughly a month to make sure it all sticks.
Typically I read the book a chapter or 2 at a time mattering how much information it covers. Mattering how technical it is I will write down every word I either don't know or second guess.
I will read over the code examples fully. At the end of the chapter I will try to recall the code example in my head, and see if I can replicate it. Mattering how good or bad that goes I will then move on or write the code out.
I keep notes the entire time I am reading. It helps keep me focus on the subject matter. My mind loves to wonder to much, and I have to beat it like a alien from the fourth dimension.
Also the notes act as long term reference as well I can review them every night for roughly a month to make sure it all sticks.
I have read ALL the comments below. They are ALL excellent.
I have a BS in Engineering, 1976, with only Fortran IV from the card key-punch days. Ugh! Worked on a defense software program and learned JOVIAL and VAX/VMS at work and C and some Unix at home. Prior, I had read Wirth's Algorithms + Data Structures = Programs. Pascal = JOVIAL = ADA.
C seemed to have the real power with access to the underlying computer via & and *. C++ appeared to fix many of C's short-comings and added many concepts (RAII). Eventually, C -> C++ -> Java.
With GNU Project and Yet Another Compiler Compiler (YACC), languages proliferated. Without a CS degree, and all the new languages, I backed off programming and switched to medicine (MD).
Years later and retired, I found that I really like sw.
I realized that I had gone to, possibly, the only college in the US that did not have C/Unix. You folks that studied C/Unix are very fortunate, and I envy you.
From 01 July 2013 to 30 June 2014, I read 3060 pages on sw.
Soon after, a legacy OS company came out with a major change to their paradigm, so I switched to Linux Mint.
I love C, Unix, Linux, Linux Mint, C++.
This past summer, I had two (2) weeks to teach my 12yo grandson, my son's son, programming. We took an old laptop, installed a new 500gb hd, installed Linux Mint 17.3-64bit, and off we went.
In 8 days, he was creating his directory structure, text editing, compiling (gcc name.c -g -o name), and debugging.
It was great fun. I bought him a used copy or K&R and K&R2.
Next summer I am teaching my other grandson, my daughter's son, the same stuff.
I read K&R in 1983. In 2013 I reread K&R. I read K&R2 every year (4 times now).
There are many ways to study, some more efficiently than others. Just do it.
My technique is to read the entire book, highlight text, take notes, work examples, and write programs.
My first short-term suggestion for a newbie is to buy and read "The C Programming Language", 2nd Edition, by Kernighan and Ritchie (K&R2).
My second short-term suggestion is to download for free and install a free Linux distribution. I like Linux Mint.
My third long-term suggestion is to pursue a degree in computer science (CS), or computer engineering from an accredited college.
>My first short-term suggestion for a newbie is to buy and read "The C Programming Language", 2nd Edition, by Kernighan and Ritchie (K&R2).
Many parts of this book, even in the first few chapters, seem like they were written for someone that's already a programmer in another language. I ended up giving up on it to use another source because it didn't seem to explain anything very well to a beginner. I'm going to attempt it again once I finish reading a gentler introduction.
Many parts of this book, even in the first few chapters, seem like they were written for someone that's already a programmer in another language. I ended up giving up on it to use another source because it didn't seem to explain anything very well to a beginner. I'm going to attempt it again once I finish reading a gentler introduction.
Do you think Nicholas Wirth's Algorithms and Data Structures is still relevant ? Should I study it ? I have an old copy
Unqualified yes but do brush up on other interesting stuff that was invented after that book was written. Still, it is surprising how timeless the content of books like that is.
I find the choice of language (C++) awkward but still I'm glad you shared that, nice story.
What do you mean by 'sw'?
[deleted]
[deleted]
Software.
Thanks. The initialism on this site is making me crazy. Please just type the full words, it's not hard.
Just start reading the entire thing front to back. Remember, you gain little from a book sitting on your shelf. The goal is not to do specific exercises, but have an index of ideas I can refer back to. Focus on new ideas / benefits and think about how I could have used them in the past. This helps to add mental hooks to keep things interesting and aid recall.
That said, I may skim sections that are less relevant to what I want to know. For completely new languages / API's I am going to need to do some coding, but 'exercises' seem to be their more so people will use books as textbooks than directly useful on their own.
That said, I may skim sections that are less relevant to what I want to know. For completely new languages / API's I am going to need to do some coding, but 'exercises' seem to be their more so people will use books as textbooks than directly useful on their own.
Let's be honest: I don't.
They sit on the shelf gathering dust until I eventually make a project needing some of the knowledge contained within. I then dust it off, scour the index for references to, say, "lock-free multithreaded programming", and read as many sections as I can about that, and as many supplementary chapters as are needed.
A few years back, in my teenage years, I read a programming book about compilers cover to cover, I don't remember much about the contents, just one or two lexing techniques and something about directed acryllic graphs.
They sit on the shelf gathering dust until I eventually make a project needing some of the knowledge contained within. I then dust it off, scour the index for references to, say, "lock-free multithreaded programming", and read as many sections as I can about that, and as many supplementary chapters as are needed.
A few years back, in my teenage years, I read a programming book about compilers cover to cover, I don't remember much about the contents, just one or two lexing techniques and something about directed acryllic graphs.
99% of the time I don't anymore. I used to read a lot, now I just pull information from the net, I have feeds of information exposing me to new ideas. Most technical frameworks have a ton of information readily available. The only books I go to are Math and Algorithm books I have on my bookshelf when I know something obscure I want is in them.
Learning falls into two categories for me
First one is the trickiest as you need ways to be exposed to something you don't know and being able to recognize its importance amoungst the flood of things you are exposed to. Things like HN are helpful.
Second one I keep notes on things I know I don't know. These often are things that I kind of have a fuzzy idea of what it does, but haven't really spent time on understanding exactly what it is. For instance, webpack is on my list, I use it a lot, I modify configs and get stuff done. I have a fuzzy idea of how works. But I haven't spent any time understanding it from the ground up and don't know how to set something up from scratch. But at some point webpack will bubble to the top of my things where I have knowledge gaps. So when I work on my chosen knowledge gap, I read a bunch of things, conduct a bunch of experiements, look on stackoverflow and look to answer questions, see how other people have solved existing problems.
Learning falls into two categories for me
- Things you don't know you don't know
- Thing you know you don't know
First one is the trickiest as you need ways to be exposed to something you don't know and being able to recognize its importance amoungst the flood of things you are exposed to. Things like HN are helpful.
Second one I keep notes on things I know I don't know. These often are things that I kind of have a fuzzy idea of what it does, but haven't really spent time on understanding exactly what it is. For instance, webpack is on my list, I use it a lot, I modify configs and get stuff done. I have a fuzzy idea of how works. But I haven't spent any time understanding it from the ground up and don't know how to set something up from scratch. But at some point webpack will bubble to the top of my things where I have knowledge gaps. So when I work on my chosen knowledge gap, I read a bunch of things, conduct a bunch of experiements, look on stackoverflow and look to answer questions, see how other people have solved existing problems.
> Things you don't know you don't know
Is Donald Rumsfeld a parent of yours ? ;-)
Is Donald Rumsfeld a parent of yours ? ;-)
I try to avoid programming books. When reading I prefer being disconnected, laying down in a comfy sofa/bed with a hot beverage. Programming books doesn't work very well for me because they make me want to try out the things I read about, forcing me to be at the computer. Some of them even assume you are sitting at the computer, ready to run examples..
If the goal is to improve as a programmer and books being the medium I choose books that doesn't necessarily have an obvious link to programming but benefit my thinking around it. Books on design, architecture, media and education being my favourite. I don't follow any particular techniques but have grown into some habits (reading ~50 books a year). I read multiple books at the same time (~3-4), usually very different in style/topic, alternating between them. This way I never get bored. The new books I choose for reading has to spark some excitement/passion in me, otherwise I'm never going to finish it. It could be as simple as some concept in a book that triggers curiosity, then I just follow the reference/bibliography and further do some quick research (amazon/goodreads) to see whether it looks like a promising book.
Reading about product design will make you a better software designer.. Reading about media will make you see how your application fits in a bigger picture.. ..and so on.
If the goal is to improve as a programmer and books being the medium I choose books that doesn't necessarily have an obvious link to programming but benefit my thinking around it. Books on design, architecture, media and education being my favourite. I don't follow any particular techniques but have grown into some habits (reading ~50 books a year). I read multiple books at the same time (~3-4), usually very different in style/topic, alternating between them. This way I never get bored. The new books I choose for reading has to spark some excitement/passion in me, otherwise I'm never going to finish it. It could be as simple as some concept in a book that triggers curiosity, then I just follow the reference/bibliography and further do some quick research (amazon/goodreads) to see whether it looks like a promising book.
Reading about product design will make you a better software designer.. Reading about media will make you see how your application fits in a bigger picture.. ..and so on.
When I started out it took a couple of books "c,c++,java" to realize most started from scratch and taught you functions and loops over and over and walked you through a simple program but I needed to find my own way to challenge myself. Eventually I just decided I wanted to build things and fought my way through documentation and the internet to get it done learning the challenges and problem solving. These days I look for more books on theory and from people who solved large problems.
Generally, cover to cover, going as quickly as I need to in order to avoid losing interest and abandoning it. This is probably not the most effective way to absorb the material. I would learn more by doing the exercises, taking notes, etc. But when I've tried to do that, I usually don't get more than a couple of chapters in before I run out of willpower.
So these days, I figure absorbing half of the whole book is better than absorbing all of only a small prefix of it.
So these days, I figure absorbing half of the whole book is better than absorbing all of only a small prefix of it.
I think I’ve followed the same method for decades.
1. Read the whole book in one sitting, to get the big picture in my head, and build a mental model of the thing.
2. Implement a toy project using the thing. Maybe an hour or two. Go back to the book for details as needed.
3. Look up something once or twice when building my first real project.
4. Never read the book again.
In spite of the short time I spend with them, it’s so valuable to be able to read at high speed, on paper, a comprehensive bunch of code and concepts.
1. Read the whole book in one sitting, to get the big picture in my head, and build a mental model of the thing.
2. Implement a toy project using the thing. Maybe an hour or two. Go back to the book for details as needed.
3. Look up something once or twice when building my first real project.
4. Never read the book again.
In spite of the short time I spend with them, it’s so valuable to be able to read at high speed, on paper, a comprehensive bunch of code and concepts.
With books that teach a language or advanced stuff about a language, like, say, C# in Depth, I read from start to finish, without actually doing any exercises or really anything else.
I trust my memory enough to rely on remembering that "C# in Depth was talking about this thing", when I run into something IRL. Then I go back to the book and see what it had to say.
I trust my memory enough to rely on remembering that "C# in Depth was talking about this thing", when I run into something IRL. Then I go back to the book and see what it had to say.
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 <topic> 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 <topic>. 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.
> 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 <topic> 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 <topic>. 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.
1. Preview / Questions - Take a gander at the chapter by reading the introduction, headings, sub-headings, diagrams, images, example code, summary, exercises, questions, etc. Also, write down questions as I preview for myself to answer after step 2.
2. Read / Recall - After previewing I start reading in full. During code examples I like to soak them in without running them. Then I'll close book and try to recall the code by typing.
3. Teach / Explain - I follow up with pretending to teach / explain the code examples and my exercise solutions out loud. This helps me figure out what I didn't really understand.
4. Project - I try and apply what I've learned from book to a personal project.
2. Read / Recall - After previewing I start reading in full. During code examples I like to soak them in without running them. Then I'll close book and try to recall the code by typing.
3. Teach / Explain - I follow up with pretending to teach / explain the code examples and my exercise solutions out loud. This helps me figure out what I didn't really understand.
4. Project - I try and apply what I've learned from book to a personal project.
I have a bookshelf full of ones from the 90s and early 2000s, but I haven't read one in years. I mostly learn from internet articles now.
Back then, when I would get a book on a subject I was familiar with, lets say C#, I would skip to the chapters I felt I needed more understanding of or what interested me at the time. (technique #1)
If it's a brand new technology, I'll read the intro chapters that go over the basic stuff (technique #2) to help me get accustomed to the syntax and nuances of the technology, then apply technique #1 (which could be the rest of the book for new stuff).
Back then, when I would get a book on a subject I was familiar with, lets say C#, I would skip to the chapters I felt I needed more understanding of or what interested me at the time. (technique #1)
If it's a brand new technology, I'll read the intro chapters that go over the basic stuff (technique #2) to help me get accustomed to the syntax and nuances of the technology, then apply technique #1 (which could be the rest of the book for new stuff).
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.
Books are great but many times, they spend so much time on information that I don't need instead of the practical stuff.
Skim the book making notes of key parts with pen and paper. The act of making the notes is usually enough for me to commit enough of it to memory to know what to look for when I need it so I get generally don't need the notes again. Then I get going on a simple project that is of relevance to me rather than the one in the book and use the book for reference as necessary.
I believe its important to interact or ask your doubts upfront instead of keeping it to yourself. I'm currently reading Haskell and I use freenode irc channel to ask my queries. The channel community is so helpful in clearing my doubts, in fact they could give much more easy / right approach for the problem than the text book solutions.
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.
[deleted]
Long time I haven't, but when I did, I usually read three or four first chapters in a row, then jumped to certain chapters that I specifically needed.
Also most of the times, the intro and the very first chapters are optional, motivational.
Also most of the times, the intro and the very first chapters are optional, motivational.
Choose a good book. Read a chapter or two before breakfast. Run all the code examples in your head (probably not needed, just my OCD -- same thing with being reluctant to trust calculations without redoing them myself).
By not stopping at chapter 1. Depends on the framework to go all in or chapter by chapter. Also a GitHub repo for each book is an excellent idea.
Check out How To Read A Book by Mortimer Adler. Great resource for techniques for understanding many different kinds of books.
if you spent an hour each day, 40 mins is taking notes on a legal pad, reading, trying stuff, etc. The remaining 20 mins is writing in a notepad the key concepts, summarizing from the other 40
sometimes read it all and intend to go back and do exercises, sometimes read it all and actually do them on the way. Probably not all of them.
I don't.
Do you read it in one go and later try examples or go through entire book by trying all examples?
Do you read the entire book or just the part to get the job done?
What methods/techniques have you found useful while reading such books?