Takeaway #3: Take Your Time

Each chapter gets started with a bit of a warning: slow down and take your time.

Here is one such example from Chapter 1: About this Book:

I emphasize the word journey because knowing JS is not a destination, it's a direction. No matter how much time you spend with the language, you will always be able to find something else to learn and understand a little better. So don't look at this book as something to rush through for a quick achievement. Instead, patience and persistence are best as you take these first few steps.

Which is iterated again in Chapter 2:

Please don't expect this chapter to be a quick read. It's long and there's plenty of detail to chew on. Take your time.

And again in Chapter 3:

Don't run so quickly through this material that you get lost in the weeds. As I've said a dozen times already, take your time. Even still, you'll probably finish this chapter with remaining questions. That's OK, because there's a whole book series ahead of you to keep exploring!

And it’s true. With Get Started, you do need to slow down to get the maximum benefit from the book. This can be true of many books. But for those who have taken my Get the Most From Technical Books free email course, you know that I am also about speed and extracting the most value from the time you invest. This does not mean extracting everything from the book that it has to offer.

The passages above give me mixed feelings, but I will start with the good:

I agree that when learning, it’s absolutely essential to slow down to absorb material, and there are tactics that can help you absorb material better. That’s why I also built my free Instant-Learner Guide, which you can get from the Books on Code homepage.

Some great tactics to slow down and get the most from the material is by self-quizzing and taking notes by hand (in fact, I made flash cards for Chapter 2 on Cram.com).

Making yourself use and manipulate the information solidifies the connections in your mind. In my Instant-Learner Guide, I use the metaphor of relational database, since ‘learning’ ought to be reframed as making retrieval easier and easier. You need to optimize your brain’s search algorithm.

Many great technical books on programming also tell you to slow down. The Head First series (that I always rave about) makes clear that all of the games and Q&A sections are mandatory activities. When the book poses a question, answer the question. Get out a pencil. Write directly in the book, because that’s how you’re going to learn.

My previous review of Grokking Algorithms similarly encourages taking your time by answering the questions it asks throughout the book. It also provides many natural breakpoints through white space and illustrations, so that slowing down is natural.

But perhaps by now you’re sensing my gripe with Get Started: it tells you to slow down, but the book is not actively working to help you to slow down.

Ways the book can do this is by asking questions and providing bullet-pointed summaries and natural breakpoints. The book is dense in content and written mostly in paragraphs. Just by the nature of the structure, it’s harder to tell where the emphasis is and extract the key nuggets of wisdom from the text, since the knowledge is presented with equal emphasis.

Reading Get Started requires that you put forward more work to understand the material, but Get Started is so dense with wisdom, that is so hard-won and valuable, that the tradeoff can be worth it.

But before moving on to the next section, a little story:

I was recently at a week-long immersive training to use a complex piece of software. The instructors were fun and kind; they put a lot of love into the curriculum they produced for us, but there was a problem:

It was the documentation.

The students kept asking questions to which the instructors, frustrated, would say, “It’s written right here,” and point to the documentation. Then they would instruct us to “slow down” and “read it again”.

Since working in technical writing at a large software company, I can say definitively that it doesn’t matter if “it’s right there in the text”. The structure is everything.

Writers of technical documentation take great pains to do all of the thinking about and structuring the material so that the reader doesn’t have to suffer deciphering.

Hierarchy is important when thinking about documentation. When everything is equally weighted, with every piece of knowledge equally as loud, the reader is less likely to benefit fully from the text, dealing with that overwhelming ‘drinking from a firehose’ feeling.