Ask HN: How do you read programming books?

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").

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.

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.

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

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.

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.

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.

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.

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.

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).

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'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.

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 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.

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.

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.

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.

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.

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.

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).

I don't.

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.

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

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

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.