
Ask HN: How do you read programming books? - pvsukale3
How do you read a programming book? By programming books, I mean books which teach a language&#x2F;framework&#x2F;tool.<p>Do you read it in one go and later try examples or go through entire book by trying all examples?<p>Do you read the entire book or just the part to get the job done?<p>What methods&#x2F;techniques have you found useful while reading such books?
======
oceanghost
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

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

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

------
jasode
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](https://en.wikipedia.org/wiki/Sturgeon%27s_law)

~~~
andrewstellman
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...](https://www.projectmanagement.com/blog-
post/34188/Head-First-Agile-with-Andrew-Stellman-and-Jenny-Greene)

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.

~~~
jasode
_> 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/...](https://www.amazon.com/Calculus-Dummies-Lifestyle-Mark-
Ryan/dp/1119293499/)

[2] [https://www.amazon.com/Head-First-Networking-Brain-
Friendly-...](https://www.amazon.com/Head-First-Networking-Brain-Friendly-
Guide/dp/0596521553/)

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

~~~
jasode
_> , 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.

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

~~~
Ace17
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>".

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

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

~~~
mailx
Did you take "Learning How to Learn" by Barbara Oakley?

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

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

~~~
awa
OT: The book "How to read a book" drives home the importance of skimming a
book and how to do it well.

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

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

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

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

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

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

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

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

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

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

~~~
copperx
What do you mean by 'sw'?

~~~
jacquesm
Software.

~~~
copperx
Thanks. The initialism on this site is making me crazy. Please just type the
full words, it's not hard.

~~~
jacquesm
yw ;)

~~~
senorsmile
Lol

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

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

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

    
    
       - Things you don't know you don't know
       - Thing you know you don't know
    
    

I also learn things well when I do active experimentation.

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.

~~~
jmnicolas
> _Things you don 't know you don't know_

Is Donald Rumsfeld a parent of yours ? ;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
ncfausti
Check out How To Read A Book by Mortimer Adler. Great resource for techniques
for understanding many different kinds of books.

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

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

------
janci
I don't.

