Is Reading Important for Developers?
I talk quite a bit about improving as a developer, specifically discussing various ways to study from a practical perspective. However in this guide I want to specifically answer the question: is reading important for developers?
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a free Dev Camp account

The short answer to the question is: yes! However as computer scientists it’s poor form to simply take someone at their word. So let’s dive into why reading is critical to improvement.

Why is reading important for developers

Let’s analyze a few key statistics in regard to reading.

CEOs and Reading

How many books do you currently read a year? If your answer is that you’re too busy to read entire books, let me ask you another question: are you busier than the CEOs of the world’s most successful companies? Probably not.

However research from the Rype Academy shows that CEOs such as Elon Musk, Mark Cuban, and Peter Thiel read around 60 books a year! That’s 4-5 books each month.

Compounded Learning

So why do some of the most successful individuals in the world take the time to go through so many books? At a high level it may seem excessive, however if you truly believe that knowledge is power, wouldn’t it make sense to dedicate whatever time is needed in order to attain more knowledge?

If you look at reading like a form of linear learning, than yes, reading would be a waste of time. Linear learning would be a 1 to 1 transfer of knowledge. For example, if it took the author of the book 10 years to research a topic and it took me 10 years to go through the book, that would be pretty pointless. At the end of the day this type of reading would be pointless.

However I look at reading like it’s compounded learning. What is compounded learning? Good question! Compounded learning is the process of taking the knowledge from an individual, but not having to spend the same amount of time that it took that individual to research the topic.

Compounded Learning Case Study

For example, imagine that you read a book on How to Become a Better Developer. The author of the book had to spend years researching the topic (assuming that it was a well written/well researched book). However if you go through the book in a few weeks, that means that you were able to gain years worth of knowledge in a few weeks!

Research shows that top authors will spend a minimum of two years researching a book. And that research time doesn’t take into account the fact that authors draw on their entire lifespans’ to write a book. All of this means that each time you read a book it’s as if you were able to gain a lifetime’s worth of experiences and wisdom from the author.

The CEO Who Didn’t Have Time to Read

A few years back I was offered a CTO position for a startup in New York City. The job had a good salary, great stock options, and an excellent product.

However during a dinner meeting with their Founder/CEO I asked him about a book I had finished reading that discussed best practices for tech startups. He said that he had never heard of the book. This wasn’t a problem, there are millions of books and I don’t judge someone for having different literary tastes than myself. However the CEO followed this statement up by saying that he didn’t have time for reading. He was too busy building the business.

The CEO’s view of reading resonated with me during the job consideration process. And I ended up turning down the job. If the CEO didn’t dedicate time to read and learn from others. That means that he would be relying solely on his own knowledge and life experiences. And even the most brilliant business person will fail if they think that they already have all the right answers.

My Reading System

It’s one thing to say that reading is important, it’s another thing entirely to go through a large number of books on a regular basis. With that in mind I’ve developed my own reading system. This system also takes into account a number of complaints that I’ve heard others say about reading.

Reading Schedule

First and foremost I schedule a set amount of time each day for reading. Usually this equals around 1-2 hours, however on weekends this number can be double that number. At any one time I’m usually going through a dozen books ranging from mind/skill hacking through technical programming books.

Audio Books Are Books Too

I’m not sure where the stigma of audio books came from. However with my travel schedule I’ve discovered that audio books are an invaluable tool in my learning arsenal. Obviously you can’t go through programming books via Audible. However you can go through skill and business based books. And I personally have hundreds of books in my Audible account, many of which I’ve gone through multiple times.

In fact, many of the books I’ve discussed and quoted from were books I listened to.

Books are Too Expensive

One of the top complaints I hear from students is that books are too expensive. My response is always: if you’re not willing to sacrifice to improve, then you’re not going to attain your goals. And that includes sacrificing financially.

With that being said, there are ways that you can go through a large number of books, even if you’re on a budget. To start off, your local library has countless books that you can learn from each day. And assuming that you bring the books back on time, a library is a completely free option. I have a library within walking distance of my home in Scottsdale, AZ, and I will visit it a few times a week to discover new books.

Additionally, you can sign up for book memberships. Safari Books Online offers an All You Can Read package. I have this membership and have gone through a large number of technical programming books in their database through the years.

Summary

In summary, is reading important for developers? I believe that it is. Reading enables you to activate compounded learning. And if you have the chance to gain years worth of knowledge and experiences in a few weeks, it seems insane to pass up on an opportunity like that.