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?
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
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.
However, I didn't become amazingly successful in life.
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.
I still second your system. Makes me wanna try.
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)
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
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.
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!
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.
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-...
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).
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.
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.
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.
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>".
Sometimes, though, you just really need help coming up to speed on a bunch of accidental syntax and incantations to get the job done.
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.
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").
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Is Donald Rumsfeld a parent of yours ? ;-)
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.
So these days, I figure absorbing half of the whole book is better than absorbing all of only a small prefix of it.
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.
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.
> 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.
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.
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).
Books are great but many times, they spend so much time on information that I don't need instead of the practical stuff.
Also most of the times, the intro and the very first chapters are optional, motivational.