---
tags: nc-programs
title: How to Survey
description: This is a brief note about how to survey large volumes of new information.
image: https://near.org/wp-content/themes/near-19/assets/downloads/near_logo.svg
GA: UA-188414449-3
---

#### How to Survey

Reading large volumes of text and code exposes your mind to patterns of human and computer language that will make you a better developer. Specifically, reading will give you language with which to think and reason about the work you’re doing. Reading structured, coherent sets of topics in book form helps you organize your own thoughts about the lessons and language you’re exposed to at any given moment. Reading structured, coherent code helps you recognize what good code looks like. Once you’ve committed to consuming large volumes of text and code each week you’ll often hear yourself saying, “I saw that last week in this book or that project” or “I’ve never seen this before, I wonder if it’s right.”

There’s a related bit of research called the Sapir-Worf hypothesis about how language shapes our thinking. You’ve probably heard someone ask “if you don’t have a word for it, can you even think a thought?” Whether or not you buy into the ideas behind this hypothesis, basically that “you can’t think a thought if you don’t have the language to represent it”, you should try this idea of surveying and see if it works for you. Some students have experienced a profound shift in their levels of confidence and ability to retain the lessons every day just by following this One Neat Trick™

Surveying includes the activities related to skimming 1000 pages of printed text and 5000 lines of code each week. The goal is to deliver massive, overwhelming exposure to force you to ignore the details and pay attention to the patterns of software development. Simply put, it's a way of discovering what you don't know you don't know. The benefits appear after only a week or two as you open your tenth book on Ruby, for example, and realize that it's very much like the third and fifth ones that you skimmed last week. If you find this hard to imagine, it's probably because you've never skimmed 150 pages in an hour every day for a week. You quickly get your bearings, and when you decide to focus in on a particular area, you already know where to find out more about it and how it fits into the bigger picture. This is so very valuable in the early days of your learning and a critical skill to master if you want to stay ahead of the state of the art. The sooner you start doing this, the better.

Regarding the process of skimming a book, we're talking about 2-300 pages of printed text, diagrams, code, etc. Many software development books tend to be fattened up so they take up more shelf space so you can rest assured that not all of the content in the book is important. Your goal then is to spend as little time as possible finding out what's important in the book. The process you use to move through the book should be consistent at first, at least until you build a sense of what you can actually learn from moving at a pace of 3-5 pages per minute through the material with a few breaks.

Start by taking a look at the front cover and the back cover -- get to know the book as your own. Look up the 3-star Amazon reviews about the book as well as the author(s). These first 5 minutes will help give you a sense of who's writing to you and what everyone else thinks of this book. This will help justify the investment of time and attention that you're about to make. If the book has terrible reviews online you can just put it down right there and not bother with it -- move on to the next one, you've just saved yourself a whole hour! If instead the book has amazing reviews, then it's probably something that you want to invest in and you don't want to wait too long before making that investment because you might be missing out on something that can help you today.

> So far you've invested a total of 5 minutes.

Once you've decided that you want to commit to skimming the book, open up the table of contents and read though it multiple times, not just once. A good rule of thumb is to read it as many times as there are levels of indentation. If it's just a high level table of contents with 5 bullet points, reading it once is plenty. If, instead, it's a more detailed outline of the book then it'll be wise to start by getting to know the structure before you start skimming to help orient yourself and maintain a sense of context while you skim. As you skim the table of contents, think about the structure of the book and try to rationalize it. Create a story in your mind about why you think the book is structured this way. Is it because the later chapters are more complicated or just less common and more like an afterthought? Is it because there is some necessary front matter to the book that helps you build up your understanding for later chapters or just a formal introduction to some of the boring details before you get to the good stuff? It might help to think of the book as a store filled with survival gear right at the brink of a great adventure in your life. You only have a few minutes to survey everything in there so it's not exactly shopping time but you can always call back for supplies later ... as long as you know what you want when you make the call. Build the structure, build the story, get to know the book.

> So far you've invested a total of 10 minutes.

The next mistake most people make is to just turn to the first page of the book and start reading. But why?! There's absolutely no reason to read the book cover to cover, from start to finish, in the order it was printed. You're goal isn't to read and memorize the contents of the book. There's no book report due or comprehension quiz at the end of this. Your singular goal is to get yourself through the book. You see, your enemy here isn't lack of perfect memory or poor recall, your enemy is never opening the book in the first place because it takes too long to read it. And it's much more likely that you'll actually get through the book if you're energized and excited the whole time. So why not start by getting yourself energized and excited? Start by skimming the most exciting chapter first. Doesn't that sound exciting? If you felt a little thrill there you might enjoy this. At first it feels like you're breaking some kind of cardinal rule about reading. Forget about all that, this is your adventure. Jump right to the most interesting chapter (for you!) and skim it. Don't worry about prerequisites or what came before this chapter or whether or not you'll understand it. Again, this is about exposure, not about deep understanding. The deep understanding will come over time, while you're on the adventure and living in the wilderness. Now is the time for discovering what tools you might want so later you can call back and have them delivered (ie. read the relevant chapters when you need them).

Imagine yourself reading 5 or 10 books a week. It's hard for most people since we were never given permission to move at this pace. There seems to be some core belief we've all bought into about how you have to maximize recall when you read and if you don't remember the details it means you did something wrong. It's utter nonsense. Using this approach your level of understanding will rise to a completely different level than if you invested a whole week reading just one book or less. We're talking about massive exposure, a thousand pages a week. That's 3 to 5 books every week, at least. Some people can cover more.

Go to the chapter you've picked to read first, whichever it is, as long as it's the most exciting chapter for you, and skim that chapter as many times as you skimmed the table of contents. First, sweep over the headings and then over the chunks of code and related text that annotate the code, and then look more closely at any diagrams. Of course you can start with the diagrams instead. However you want to move through that chapter, just make sure that it's exciting and energizing in a way that helps you keep that momentum up.

> So far you've invested a total of 15 minutes.

Once you've done that, go back to the table of contents. Skim it again a couple of times then pick your next most interesting chapter. You can do this back and forth for about an hour or two.

At first it's going to be exhausting for you. The first couple of times you do this it might feel like a waste of time. But once you get into the habit of it, you'll find yourself able to pick up a book, any book, and survey it in about an hour or two to get a very good sense of what's in there. If every week you're adding 3 or 5 books to your awareness, you can then go back and read those books more carefully at exactly the right time when you need it.

Instead of picking just one book that you punish yourself with every day you fall asleep reading it, what you have over the course of each week is a very good idea of the contents of 3-5 new books, or almost 20 books each month.

Exactly the same dynamics happen with skimming 5000 lines of code each week but for slightly different reasons. If you're reading that much code you'll quickly develop a sensitivity to some of the most important parts of writing software: proper indentation, file and folder structure, naming, syntax, etc. You will learn to recognize syntax that you didn't even know existed in your language -- a perfect example of something you don't know you don't know. You'll start to recognize some ways of structuring your program that maybe you weren't even aware of. You'll build a kind of sensitivity to good coding practices. You'll start to see that good code looks a certain way, and you'll feel a little bit uncomfortable with code that isn't properly indented or isn't properly formatted, or isn't properly documented. You build this awareness because you're looking at so much of it that your mind will learn to recognize the patterns and these patterns will help you learn more quickly.

The same process can be applied to videos and courses online. You just play the videos at 2x speed. At first it may seem too fast to be useful but after a minute or two you start to make out the ideas being communicated.