What's on Your Programming Reading List?

By: Amy M Haddad

“I think you need to read more,” my professor told me bluntly. I’d just shared my idea for an upcoming paper, and he clearly wasn’t thrilled about it.

“Read more?” I remember thinking. I wasn’t expecting that response. I walked out of his university office trying to make sense of his comment.

So I read a lot over the next few weeks. My knowledge grew tremendously—and so did my ideas, which inspired a new and improved paper topic.

That experience, which was about a decade ago, taught me a critical lesson: the benefits of reading avidly and broadly about your field. What began as a one-time thing to do well in a class has turned into a lifetime habit.

Interestingly, I received similar advice when I began writing professionally. I was constantly told to write a lot and read a lot.

Given the emphasis on reading up to that point, you can imagine my shock at the attitude toward reading when I began to program. It seems to be a low priority for many people.

In the world of programming, reading includes reading code and reading technical books. I’ve written previously on why reading code matters and how to go about it.

Now it’s time to tackle reading technical programming books.

Why Books?

Reading technical programming books is one habit programmers should begin immediately. It’s a relatively small investment that’ll help you now, but will pay dividends in the future for this simple reason: your knowledge will compound over time.

The question you’re probably asking is this: why books?

After all, we spend a bulk of our days glued to the computer, where we have access to a seemingly infinite amount of material (and so much of it is free).

As a producer of online content, I realize that online articles and blog posts have their place. Blog posts can give you an interesting perspective and exposure to a new idea. A technical article or the documentation for a language or technology can answer that specific question you have.

But books have their place, too.

They fill a different need: they’re a source of long-form content that take you on an in-depth journey about a particular topic. A blog post or technical article may be a few hundred or thousand words. A book is tens of thousands.

When you pick up a technical book, you take a deep dive into said topic. You pick up the nuances. You study, practice, and learn. You get into the mindset of an industry expert. You begin to see things differently, as your context begins to grow.

There’s no shortage of topics to read about in our field:

• Computer architecture
• Agile software development
• Algorithms
• Testing
• Writing clean code
• Refactoring

The list goes on and on.

Even in the age of everything digital, it pays to begin your own library of technical material. So invest in some technical books. Use them. Write in them. Reference them as you code to help you build good habits.

How to Find the Time

The challenge, of course, is finding the time to fit something like reading into an already packed schedule.

But if people like Bill Gates and Warren Buffett—who are known to be vast readers—can find time to read, I’m convinced we can, too.

Consider mathematician Richard Hamming. He, too, figured out a way to make reading a habit, which he shares in his excellent lecture, You and Your Research.

Hamming couldn’t understand how his colleague, mathematician John Tukey, knew so much. “The guy was clearly a genius,” Hamming recalls. So he went into his manager’s office to find out.

“Hamming,” his manager said matter of factly, “you’d be surprised how much you’d know if you worked as hard as [Tukey] did.”

Hamming reflected on his manager’s comment and decided to “reorganize” his life. He cut out “nonsense magazines” and spent time “studying things in [his] career.”

There was always a book on his coffee table “ready to be read.” He also got appointed as a book review editor, so he could review the books he read. “This way I forced myself to get a wide acquaintance in computer science,” Hamming remarked of the process.

“I wasn’t a first-class genius,” Hamming explained. “So I simply set aside those other things [like reading the New Yorker] and did that,” he added. “It’s not hard to do. You just do it.”

What We can Learn from Hamming

There are a few critical points we can glean from Hamming’s story.

First, he always had a book on his coffee table. In other words, he always had a book in sight. This visual sends a kind reminder to read.

If a coffee table doesn’t work for you, try keeping a programming book next to your computer or nightstand. Perhaps placing a book by your television stand is best. That way, when you reach for the remote control, you see the book you ought to be reading.

Second, becoming a book editor seemed to hold Hamming accountable both for reading and for making sense of what he read.

After writing a review, he let it sit for a week. Then, he’d ask himself these questions: “Is that a good review? Does that really digest the book?” If not, “you’re re-reading the book and writing a better review.”

In today’s world, the process is even easier: read a book and write a blog post on it. Indeed, writing is a great way to solidify your knowledge.

That's an important point: do something with the content you're reading about. Hamming chose to write reviews. But there are other ways to go about it.

While reading, use what I call the “spot check” approach. The idea is to randomly check your knowledge as you learn new material. After reading a paragraph or two, pause, and see if you can recall and articulate what you just learned about.

Another idea is to type some notes summarizing key points after you read a chapter. The process itself is useful to review and reinforce important points.

Then, you can use the notes you type in different ways:

• Make Anki flashcards, so you’ll constantly see the information in the future.
• Make a checklist. After getting feedback on my variable names, I read about naming in the book Code Complete. Then, I made a “variable name” checklist. It hangs on the wall in front of my desk.
• Focus on something specific you learned about while coding. I recently read some useful information about writing tests. Now I pull up these notes and reference them as I work.

The point is to apply what you’re learning. Take the information you're gaining, connect it, and turn it into knowledge.

Make It a Habit

In large part, making reading a priority is a matter of attitude.

You’ve got to realize that reading matters. And to realize that reading matters, you’ve got to see the benefits. When something is important and we see the benefits, we find a way to make it happen.

There’s an easy way to do it: start with reading only 30 minutes each day for a month. It’s a small, manageable investment of time. And yet it’s enough to have an impact.

Whenever I add something new to my life, I find it useful to cut out something else. That way, I don’t add more stress trying to fit it all in.

At the end of the month, take inventory and see how much you learned. The odds are high that you’ll be shocked by how much you learn. You’ll either find ways to continue the habit or you’ll find ways to spend even more time reading.

The professor who told me to “read more” ignited my motivation to read, albeit initially to get a good grade. But I quickly saw the benefits. As it turned out, this professor, who I later learned has over 1,000 books in his personal library, gave me some of the best advice I’ve ever received.