Fog Creek Software
Discussion Board




How to Read a Computer Book

In the what does a great programmer know thread below, Timothy Falconer had on his list "how to sit down and *STUDY* a computer book or manual, straight through, for its own sake."

Most of what I've learned before has been in classes, where I have to confess, I let the grade be the measure of how well I had learned a topic.  Now I'm in the real world, and want to develop better habits.

So, do people do all the exercises in a book?  Skim five books on a topic or devour one?  How do you choose which book to read?

Also, how much during work reading time is cool for a junior programmer?  I sometimes feel like I'm wasting time during the day until I can get home to study a topic I'm unclear on.

Mary K.
Tuesday, March 26, 2002

Here's how I do it:

1. read the table of contents completely
2. read the synopsis of each chapter in the intro
3. quickly skim the index

.. for each chapter ...
5. skim highlights in the chapter before the last (if any)
6. completely re-read highlights in the last chapter (if any)
7. page through the chapter, skimming everything
8. read the chapter, highlighting what I want to remember

I got this procedure from the book "How to Read a Book", which is quite good.  Some might think this is obvious, but it's not.  Repetition is crucial, as is the idea of limiting the amount you need to re-read each time you review it.  If something is particularly tricky, I'll make the extra step of outlining the points I want to remember in a seperate document, then review those as well.

Why do this?  Because you never know the usefulness of a piece of knowledge until you really need it.  Waiting until you have a specific problem before looking for the answer can be very counter-productive (though of course it's a necessary and valuable skill). Often an hour spent studying can eliminate tens of hours spent doing things the wrong way because you didn't know something. 

Also, most technologies require a solid context to understand how everything fits together.  It's usually impossible to get a real solid context with on-demand trips to your manual (or USENET). 

Here's an example:  for years, I used Photoshop for quick tasks.  One day I needed to cut out an image, so I read about the magic lasso (or just played with it).  Eventually, after screwing around forever, I sat down with Photoshop Bible and started from the beginning.  Now I understand channels and quick-mask and levels and curves.  It's a different world.  I never really understood Photoshop until then, and in the first five years I used it, I wasted tons of time.

The classic metaphor is "sharpening your saw".  A man runs into a woodcutter in the forest who's working real hard to saw down a tree.  The man says, "Why don't you sharpen your saw, you'll be able to cut the tree faster."  The woodcutter says, "I don't have time ... I've got to cut down this tree."  As a result, the woodcutter takes three times longer to cut the tree than if he sharpened the saw *and* cut down the tree.

Always sharpen your saw, even if you don't think it's necessary.  If your work environment views this type of study as unproductive, give 'em a good whack on the head.

Timothy Falconer
Tuesday, March 26, 2002

I own "How to Read a Book." Bought it several years ago but never got around to, er, reading it. Perhaps I should dust it off. Very high acclaim all around from those who have read it.

Now if GEB had put his arguments as eloquently as you, our discussion (in *that* other thread) things would've gone very differently. See, here I agree that "Usenet is no substitute for studying." On the other hand, Usenet *is* a great tool for getting your mental feet wet, being exposed to a broad range of ideas, and asking for specific help when you're stuck (or searching for it if it already exists). It also helps to be involved in a community of people you consider peers.

Mark W
Tuesday, March 26, 2002

This is just from my experience

1. For most decent books, I would use Tim's outline. It's simple and perfect for progressing up the knowledge tree.
2. For most books by Wrox/SAMS/Whatever/14/21days (you know the ones, the heavily padded books with lots of code samples and tons of mistakes), simple go through the book, read sequentially (whether you get an understanding or not), and type out the code sample. (Note the emphasis is on TYPING, as it's part of a mental exercise to help reinforce the coding concepts). Most of the writing and explanations are junk anyways, since all they do is regurgitate vendor documentation.

I'm really surprised that there aren't more "workbook" type books in computer programming, where a person goes through a set of exercises and comes out slightly more enlightened than when they came in. If you've ever been to a high-end training seminar, you know that all the knowledge is gleaned from the exercises, and the trainer (I don't care how famous he/she is) is just reading through a list of exercises to begin with.

The computer book industry has way too many "This is my way of doing things in XXX technology and this is why you should use XXX!" (replace XXX with java/activex/.net/or any other buzzword) books as opposed to "Here are some examples that should give you pretty good coverage of this technology, try it out and see what you like".

Read what you need and discard what you dont. And don't ever let any book become a religion.

James Wann
Tuesday, March 26, 2002

or a website. ;)

Mark W
Tuesday, March 26, 2002

lol :-P

James Wann
Tuesday, March 26, 2002

I took Timothy's advice and ordered How to Read a Book from Amazon.  $12 - not bad.

Anyway, I agree with Timothy and James and have a few things to add.  The first may seem obvious, but it's not always.  That is - buy the right book.  Accuracy, completeness, and readability are the golden trinity that is often hard to find in software books.  And software books are too expensive to waste your money on bad ones.

My guidelines:
- look at sites like this, Amazon's reviews, and www.accu.org .The list on the accu (Assoc. of C/C++ Users) site is fairly exhaustive and the reviews are well written.  The Amazon reviews come with a grain of salt - throw out the best and worst, and if the reviewer writes "this book is very much teribul" then it's probably not that bad.
- if two books are similar in content and price, buy the one with a fuller set of questions and answers.
- avoid books with progressively built up programs.  If you're reading chapter 8 and the program uses a method from chapter 6, it's a minor pain when you read it the first time, but a major pain when you try to use it as a reference later on.
- avoid books written by a committee. The chapters don't tend to flow very well from one to the next and are often repetitious of previous chapters (since the one author is always sure what the others wrote, I would guess).

Coupled with the above, my take on publishers:
- SAMS Learn Anything in 21 days: I don't buy.  Who knows?  They might be good books, but I can't bring myself to buy from a publisher that is lying up front.
- Wrox: typically so-so.  Seem to attract authors that fill their books with chatty fluff.  On average, could be 50% thinner without fluff.
- O'Reilly: generally good if you already are familiar with the subject.  Usually concise and have the best binding and fonts on the market.  (I have a thing about sturdy bindings and readable fonts.)
Peachpit: For Dummies books for those of us too arrogant to buy a book called "for dummies."  You'll never be an expert reading one of these, but they are great for subjects that you only want a quick, easy-to-read overview.

For reading, I like to read through the entire text, and then work on all the problems.  If it's complex stuff, stop when things start getting fuzzy, work through all the problems to that point, then continue on. This is why I also hate books with sample exercises in the middle of the chapters.  Who wants to read, stop, go to the computer, read, stop, go to the computer, ...  Also, if you're really set on memorizing the book, then take notes the second time through.

If I get to a part that I'm stumbling across, I play the mental exercise of pretending to explain it to someone.  Several of my college professors said that they really didn't get a good grasp of some subjects until they started teaching them.  Just don't sit in your cube mumbling to yourself - doesn't look good at review time.

As far as how many of the problems you do, I don't get religious about it.  If two consecutive problems are similar in scope – combine them.  It’s a learning exercise not a homework assignment.  If several are redundant in scope, stop after the first if you think you’ve got the gist of it.

Regarding skimming five books on a topic versus devouring one, I guess I don’t see the point in spending more time and money on books for the same topic if you haven’t gotten all that you can out of one.  Last year I took a Java class, so I’d go to Marcus Green’s Java discussion forums for occasional advice. The site is geared toward the SCJP exam, so you’d find a lot of talk there about the best exam prep books.  Many people would write that they used 2 or 3 prep books for the exam.  All those books have essentially the same content.  So, I always wondered, did they really master the contents of one book before moving onto the next?  Or were they desperately seeking a magic panacea, hoping that an ‘aha!’ would leap from the pages and it would all be so clear now?

Nick Hebb
Wednesday, March 27, 2002

On this topic - I havent read a computer book for about 6 months. I just dont feel like it, but I'm devouring novels at 1-3 a week.
Does this happen to anybody else here?

Mr Jack Harrison from the outskirts of san Diego
Wednesday, March 27, 2002

If you don't already know how to read a book, then how do you manage to read a book called "How to read a book"?

Andrew Simmons
Wednesday, March 27, 2002

In reply to:
>>>>>>>
If you don't already know how to read a book, then how do you manage to read a book called "How to read a book"?
>>>>>>>

Thank you.

You have added so much to this conversation.

We are all that much smarter now.

You are not that funny
Thursday, March 28, 2002

Here is the problem with every computer book: there is at least 50 pages of fluff at the beginning of every single one, and (my books tend to focus on Java) they all go over the basics again, and again, and again (I expect this in begining ... books, but not in something like "Pofessional Java Server Programming or Java Enterprise In a Nutshell all of which dedicatea good 100 pages to JDBC or Threads or something you should already know). So what I do:

Buy/borrow book,
skip to the part that interests me,
work my way backwards- that is (if there is something that is a pre-requisite for what I want to know, I go there).

OR
skip to the part I need (rather than what interests me) then work backwards.

Within the part that interests me I read the chapter ignoring the code examples (sometimes they confuse because they skip ahead of the authors discussion), then when I am done reading
I hop on the computer, and either try to adapt the code samples to something I am doing (More common) or try them out (less common)

There is one other caveat, If I am learning a new environment- be it runtime (i.e. what is a context), or design time (put java.exe and javac.exe in an environment variable called classpath), I always read an overview first. I hate books that don't provide this- for instance when I was first learning java there were plenty of books that didn't explain how to set up the environment variables you need

Daniel Shchyokin
Thursday, March 28, 2002

My first thought when reading this thread was, "Wow, I never knew that people could make reading so much work."  On re-read, it appears that it is because most people are essentially reading manuals disguised as books.

I tend to look for books that are heavy on concepts rather than nitty gritty.  If buying a book on multi-threading, I will look for one that covers common designs rather than descriptions of how mutexes differ from semaphores.  If I am looking to learn a new language, I look for a book that starts from the language designer's intent.  Armed with the appropriate concepts, it is easier to understand and retain the details.

Having selected an appropriate book, the big trick I have learned is to use the "lost minutes" in the day.  I usually consume books while doing other things (cooking, brushing my teeth, watching TV).  Reading technical books in 5 to 15 minute chunks allows you time to really consider what the author is trying to get across and avoids the problem of reading three chapters in a sitting and not really remembering anything of what you read.  It also allows you to keep up-to-date without having add a new chore to your life.  I manage to read an average of 3 technical books and 5 technical magazines a month this way.

fancy
Friday, March 29, 2002

The most important skill is in selecting the book. In most fields, only about 10 percent of computer books are worth reading.

Avoid books written by newbies who've been paid to just re-package beta documentation and toss in acres of "sample code."

Look for books by experienced developers who are good writers. Also, bear in mind that vendor documentation is often very good, because it's been prepared by professionals and been subject to lots of review and feedback. For example, the Java tutorial series by Sun's in-house writers, Campione et al, is excellent. Most Microsoft developer documentation is excellent.

Choose carefully and don't fritter your time away on rubbish.

Hugh Wells
Sunday, April 14, 2002

*  Recent Topics

*  Fog Creek Home