How To Get the Most out of a Programming Book

Written By Tom Hombergs

As software developers, our primary resource is the web. The times when we had to consult fat handbooks with titles like “Complete Reference to …” in order to learn about a certain application programming interface or language feature are over. And I’m happy about it!

However, there are topics that are best conveyed in a book.

A book can cover a topic from end to end whereas web resources are often very specialized. It can tell a continuous story whereas web resources are often fragmented. And a book is something special for which we consciously set aside time, while we often consume web resources only casually—after all, we have paid money for the book.

So, for learning the concepts of a programming language, a software architecture style, or Agile methods, you buy a book. You’re likely to stay motivated to read through it in a couple of weeks at most, and apply the things you’ve learned in your daily software development routine.

But be honest. How often do you read the first few chapters of a book only to forget about it? A couple months later, you rediscover the book on a dusty pile in a corner and you feel bad about not having pulled through.

So let’s talk about how to make a habit of reading books and how to get the most out of it while doing it.

Choose the Right Book

Time is precious and you want to spend it on something worthwhile.

Before buying a book, you should make sure you really want to read it. Is it on a topic you need to learn to get better at your job (or to get a better job)? Is it about something you’re curious about? Does the book title actually match the content? And what do other readers have to say about it?

These questions are best answered firsthand by a colleague or friend who has already read the book. Missing that, you can consult book reviews online. However, don’t be satisfied with Amazon book reviews alone.

There are blogs out there that provide more detailed (and sometimes, more honest) reviews. And there are curated lists of books for programmers, like the one John Sonmez recently compiled. The more sources you can tap, the better your picture of the book.

Of course, you can also just buy the book and see for yourself. Then, however, you might run into a motivation trap. If every second book you buy doesn’t match your expectations, and you stop reading it after the first chapter, your “pile of shame” will grow and you may lose the drive to read any more books.

Wouldn’t it be great to continuously read books that advance your career for months or years at a stretch? Imagine the knowledge you would gain! So, once you have a book in your hands, let’s see how to get through it in no time.

Know Your Reading Speed

Like with so many other things, the best way to get through a book is to plan it out and make a habit of it. Before planning a task, however, you need to know how long it’s going to take.

How long does it take to read a book, a chapter, a page? The average reading speed of an adult is said to be somewhere between 200 and 250 words a minute. This may vary, of course, if you’re reading a book that is not in your native language or is very technical in nature.

But who wants to count words in a book to measure reading speed? To find your true reading speed for a certain book, I recommend measuring your actual reading speed in minutes per page.

Plan some time for reading the first chapter, or the first 20 or so pages. Measure the time it took and divide it by the number of pages you got through. The result is your personal reading speed for the book you’re holding in your hands.

Don’t try to deduce your reading speed for one book by looking at your speed for a previous book. It may vary greatly. When reading John’s book “Soft Skills: The software developer’s life manual,” I measured my reading speed at about 1.5 minutes a page.

Currently, I’m reading “Just Enough Software Architecture: A Risk-Driven Approach” by George Fairbanks, and this one takes me a little more than 2.5 minutes a page. The writing style, content, and font size are different for each book.

A minute more or less per page may not seem long, but multiplied by the number of pages in a book or even a chapter, this is a lot of time.

Note your reading speed somewhere safe. I usually write it on a sticky note and put it on the first page (within the cover; otherwise, it gets lost). This way, I can refer to it any time I’m planning out my reading time.

What about e-books? The minutes-per-page approach doesn’t work here, since each e-book reader has a different page size and you may even change the font size. However, e-book readers usually provide a location indicator that you can use instead of page numbers to measure your speed. If you have a cover for your e-book reader, you can even put sticky notes inside.

Plan Your Reading

Now that you know your reading speed for the book, you know how much time it’s going to take.

Just like working out, writing, or brushing your teeth, reading is most successful once you have established a rhythm and made a habit of it.

In my experience, the best way to establish a habit is to do weekly planning, which is a habit by itself. I take an hour every weekend to plan my personal tasks for the upcoming week. These include writing blog posts, preparing talks, and reading books, among other things.

For each book you’re currently reading (yes, there can be more than one at a time), count the number of pages in the chapters you want to read during the week and multiply it by your minutes-per-page reading speed.

This way, you know how long each chapter is going to take. Then block time for those chapters in your calendar or whatever planning tool you use. If the book’s chapters are too long, you can also set aside time for chunks of 20 or so pages.

I prefer to read through a whole chapter in a single session, to minimize context switching and fragmentation.

But where in your schedule should you put those blocks of time? Even though your calendar is most certainly full during workdays, don’t push your reading time to the evenings.

In my experience, focused reading after a full day of programming, meetings, and office politics is simply not possible. You may get through a book, but would you even remember what you’ve read?

Instead, try to incorporate a reading habit into your workday. Take half an hour in the morning for reading and work half an hour longer in the afternoon. You might even talk to your boss to make that reading time part of your job description. After all, you’re reading to improve your professional skills. Try to address it at your next yearly review with your boss.

Now it’s just a matter of going through with your plan. Once you’ve done this for a week or two, you’ll get into a habit and even feel like you’re missing something once you break that routine.

Don’t skip that weekly planning! Due to holidays and vacation, I skipped my planning the weekend before writing this article, and I already know that I’m not going to read a single page this week.

Persist With Your Knowledge

Once you are committed to reading a book, you’ll want to make sure to persist with the knowledge you’re gaining while reading. Otherwise, why read a book in the first place? You want to be able to talk about the contents to your colleagues and apply what you have learned in your software development.

The first step to persisting with knowledge is to take notes. Just as you’ve done in school, write down the concepts you found most interesting or that were new to you in bullet points.

Also take note of things you can connect to concepts you’ve read about in other books or to situations you’ve encountered in your software projects. Connecting newly gained knowledge to past experience is a great way to anchor it in your brain.

There are various ways to go about taking notes. Personally, I like to use a sticky note for each chapter of a book (or two if the chapters are really long). While reading a chapter, I write down bullet points about interesting concepts. After finishing the chapter, I put a sticky note on the last page of the chapter for later reference.

What’s different from school, though, is that you’re not learning for a test. You don’t want to do bulimic learning, where you forget about what you’ve learned afterward. You want the knowledge to stay with you.

The best way to persist with knowledge is repetition. Talk about it to different people. Start a conversation with a colleague or on Twitter. Or simply set aside another block of time to go through your notes again.

Even better, write about it. I like to review books I’ve read on my blog. This way, I’m forced to revisit the notes I’ve taken and to structure them into my own line of thinking, which makes it easier to remember them in the future.

Going a step further, you can digitize the information you’ve learned to make it searchable for future reference. This can be of great help for future research or writing projects.

Citavi is a tool that supports taking notes and cross-referencing, among other things. It’s targeted at researchers who have to connect information from different sources to write their own papers, but it can be used as a personal body of knowledge just as well.

What’s Your Next Book?

Reading a book, if done right, is a great way to broaden your knowledge, not only across many software development topics like software architecture or Agile methodology, but also about topics like productivity and career advice.

The fact that you’re paying money for a book, and usually reading it without distractions like emails and phone calls, makes it an inspiring experience that leads to ideas and knowledge gains you would otherwise miss.

Pick a book today and follow the simple steps above to make sure you get the most out of it!