In my experience, there are two ways to read a technical book. You can read a book to understand how to do what the book is about or you can read a book to understand what is possible.
I think this is one difference between junior and more experienced developers. Junior devs think they need to know how to do stuff. However, this actually proves to be incredibly difficult if you aren’t using the skills you are learning on a daily basis.
A better way to read a technical book is to read through it in order to understand what is possible with whatever the book is teaching. If you ever need to understand the “how”, you can simply go back and use the book as a reference.
In the moment, when you are faced with a problem, knowing what is possible is much more important as you will probably have forgotten the implementation details. Plus, implementation details are just that, details, and can be copy/pasted from the book when needed.
I personally find this second way of reading is both faster and a lot more fun and I don’t clutter up my brain with a lot of technical implementation details that I may never need.
However, I do need to add a caveat. If you are going to be using the skills on a daily basis–say refactoring your code–then you should take the time to fully understand what you are reading. This becomes less about reading though and more about studying and skills acquisition.
But once again, you can pick one small skill from the book and practice it until it becomes second nature and then go back for more. Even when trying to learn a new skill, understanding an entire book all at once is just too much work.
Leave a Reply