How doth I read a technical book?

With all that in mind, its questionable how far you can get just by book learning. Before my first child was born, I read all the How To books, and still felt like a clueless novice. 30 Months later, when my second child was due, did I go back to the books for a refresher? No. Instead, I relied on my personal experience, which turned out to be far more useful and reassuring to me than the thousands of pages written by experts.

A quote from "Learn to program in 10 years"

The above quote is from an excellent article. I've found myself thinking about it on and off since I read it. If you're like me and you read the orange site¹, you've perhaps already come across Learn to program in 10 years, as it pops up on it every now and then.

Anyway, the above snippet has me wondering about how valuable technical books are for me. In the last few months I've taken a sidestep from personal projects to focus more intently on technical books. I'm not exactly sure what drove the decision. Perhaps, my new job as a consultant has got me feeling like I need a more polished technical knowledge that my projects haven't provided for me.

I am still a strong proponent of learning by creating projects. There are two reasons for this. First, I find myself more motivated to complete what I'm working on if I am interested in what I am creating. Secondly, no matter how common the project may be (yet another todo list?), there's at least a good chance that it's different enough from what's out there that you still have to strike out on your own and learn something new / build it in a way different than what's out there.

Anyway, back to books. A few months ago, I started on a new client using Elixir. So, I decided to pick up Elixir in action and go through it. I found the whole experience to be very useful. My situation was that I had experience with Elixir through projects that I had created for myself but I did not have production Elixir experience. And while the language is similar enough to Clojure, I wanted to fill in the gaps that I might've missed while creating the projects I was working on.

The most difficult thing about taking this approach, is finding those gaps without having to read the whole book. A book like Elixir in action starts off with a whirlwind tour of the syntax of elixir. And while I "know" enough syntax to be productive, I still feel I can't skip everything ².

Recently, I've picked up Rust in Action and while I don't need to use it for my job, I want to be able to use rust for certain projects. Unfortunately, I find that it is such a complicated language that I am now going to have to resort to using a book instead of bashing my head against the compiler when something isn't working. And while I have succeeded at creating projects with rust in this manner, I'm starting to feel that I must use a more structured approach to my learning.

So, I think I need a new system when it comes to technical books where I'm already proficient enough with the subject to be semi-productive. I've got to just jump into the deep end. I need to let go of completionism. Completing the entire book isn't a real reward—I think too much too often in this manner. So now, I think I'm going to try scanning the table of contents and jumping to a topic / project / chapter in the book that seems the most suitable to my comfort level (or rather, just outside my comfort level) and see what happens.

I'll report back on how this goes soon enough.

Footnotes