Generally, I like to consume a book from front to back, but it obviously
depends on the editing. It doesn't matter much with Effective Java, but
with a book like Head First Design Patterns you'd certainly want to build
up the basics before moving into more complex double-dispatch composite
patt
You don't read books. You just buy them and put them on the shelf and wait
five years. After five years, you either go "I am glad I didn't waste my
time on that DCOM stuff!" or "They are still talking about it, it must be
something useful. Let me read it."
How you read a book depends on how
On Tue, 12 Jun 2012 21:39:18 +0200, Jan Goyvaerts
wrote:
I'm making annotations with crayon in the books - or highlighting ebooks
-
when reading interesting things. That's usually how I'm remembering it
later when the occasion presents. :-)
And skipping what I'm quite sure is not applicabl
I'm making annotations with crayon in the books - or highlighting ebooks -
when reading interesting things. That's usually how I'm remembering it
later when the occasion presents. :-)
And skipping what I'm quite sure is not applicable to what I'm doing at
work. I'm rarely reading a book cover to c
Hi all,
What are some ways you effectively absorb knowledge from reading
programming books? For language or feature specific stuff, obviously
working on a project with it is the best way to learn. But what about more
general things - stuff like *Effective Java* or *Head First Design Patterns*
?
