Reading & Writing

Leslie Lamport knows a thing or two. He's a Turing Award winner and researcher at Microsoft. He has written influential papers on distributed systems and formal verification.

Leslie Lamport says you should learn to write well, because people will judge you by your writing, but more importantly it is the key to thinking well. The better you write the better you think the better you write.

But there's something Leslie didn't say, he talked about why to write well, but he didn't say how to write well except that writing well comes with practice, which isn't horrible advice. (The clip is only two minutes long, so cut the guy some slack!)

To write well you must read well.

Moreover, reading, thinking, writing, thinking, reading is the virtuous spiral of learning. Reading gives you ideas to think and write about. Thinking generates new ideas and integrates them with what you already know. Writing tests and refines those ideas. Each iteration you are just a little better, a little smarter for the effort.

I want to read and write more...a lot more. I've been learning to improve my reading and writing habits.

Reading

People read more and more every day. People read Twitter and Facebook and Instagram. People read mommy blogs. People read emails and texts. But this is not a balanced diet. Much of what we read today is short-form, polemic, snark. It is banal. There can be a place for that, but when fed only junk food your mind will get soft and flabby. Your mind needs to get to the gym.

When I say I need to "read more," what I mean is I need to "read more long-form...mostly books." I'm also thinking mostly of non-fiction. Yes, you can acquire information through YouTube and podcasts, but that will bias you toward recent ideas and a select group of "content creators" with specialized skills and tools. You can't easily skim a YouTube video. YouTube and podcasts are no substitute for books.

Through a book you can learn from people who have been dead for 1,000 years. You can learn from kings as easily as from ordinary people who had only pen and paper. You expose yourself to possibilities outside your sphere of experience. There's a wealth of knowledge available in books, and they aren't all digitized.

While you are learning something else happens, reading (whether fiction or non-fiction) improves your language skills like spelling, vocabulary, and grammar. You can absorb different writing styles from poets, novelists, journalists, mathematicians. From this soup of styles your own writing voice will emerge.

These benefits will only come to you if you read well.

Read with pen in hand.

Research indicates that by engaging with your books you will retain more information longer. Read with pen in hand. Some use their pen for marginalia, but a more effective use will be to write the things you learn on a separate piece of paper in your own words.

To do this you need to summarize the most salient ideas. As you read periodically pause and quiz yourself. What is the author saying? How does this relate to other things you know? This will help you internalize the information as a connected graph of knowledge in your mind. The more connections an idea has the more meaning you impart to it, and the more "handles" you have to grab it and pull it out.

Both for summarizing in my own words and for connecting ideas I sometimes wait until the next day to summarize my reading, without referring back to it. This allows my mind to organize, connect, and highlight the ideas that are important to me. Sometimes I may even re-read something few times over the course of a couple of days to let my mind extract more. (Perhaps only for books that are fertile ground for interesting ideas.)

But after you decide what is important, write it down. You will make best use of the ideas if you keep some notebooks or use a note-taking app. Even if you just throw the notes away you will help your mind retain and comprehend ideas by using your own hand to write the ideas in your own words. You can do this by reading with pen in hand.

Read widely.

The more you connect an idea to other ideas the more valuable it becomes. The more you connect an idea to other ideas the more meaning it receives and the more meaning it gives. Reading widely is a great way to fill your mind with a diversity of ideas.

A recommendation system doesn't help you seek out new ideas. You have to do it. One way to do this is to go to the library, walk up and down the isles, and flip through any book that catches your eye. You may pick up only one idea. That's great! (I'll talk more about how to read ruthlessly later.) Browsing is a fine way to break out of your interests.

Sometimes you can get good recommendations from friends, family, acquaintances. Their interests may be similar to yours, but chances are they are not exactly the same. Ask: "what is the most interesting book you have read recently?" You can try asking this of people you know have very different interests from you. Perhaps even start a monthly email thread with the topic "what have you read recently?" If your friends, family, acquaintances have a hard time answering the question, maybe they'll be encouraged to read more. :)

Reading widely can take a certain amount of humility, especially when you read about ideas that directly oppose your cherished beliefs. You don't have to change your mind, but try to empathize with the people behind the ideas, their struggles, and their experiences that lead them to believe this thing. Think about the light each idea sheds on all the other things you know, and the value you will get by adding to the richness and subtlety of your knowledge web.

A rich web of knowledge will help you find creative solutions to the problems you face. I believe the most revolutionary ideas are born from the unexpected combination of seemingly unrelated ideas. Read widely to fill out that knowledge web.

Read deeply.

Breadth of exposure is helpful for your mind to draw connections between ideas, but so is depth. Your mind is a pattern matching machine. If you give it two ideas it will quickly suss out the similarities and differences.

So if you want to understand the fine distinctions in a subject, read topically. For example, if you want to study the Bible, don't look for the "best" translation, get them all. If you compare passages among translations you'll quickly get to the root of translation disagreements, and all without learning a lick of Greek or Hebrew!

When you read a book on a subject, use it as a starting point. Look through its bibliography and sources cited, and go read them. Use the recommendation system at Amazon to find related books. Go to the library shelves that contain a book and check out those near to it. Ask people for recommendations of books similar to ones you've read.

As you load your mind with information, it will go to work. It performs magic while you sleep, or while you daydream. Let yourself get bored. Let your mind wander. You'll think about ideas, how they are the same, and how they are different. Then write it all down. Reading deeply will give your mind plenty of fodder.

Read ruthlessly

If you feel your reading list getting much, much longer, then I have good news: you don't have to read every word. You don't even have to finish a book. An author has put a lot of work into a book, and you should accept that gift graciously, but the author has no right to demand your time. Unfortunately "speed reading" doesn't help here. You should learn to skim, and be OK with not extracting every idea from a book.

When reading broadly, the point is to find new ideas. If there's a book that looks interesting pick it up. Read the summary. Look through the table of contents. But if the summary and the table of contents don't induce you to read more, then put it back. If you get half way through the book and lose interest, put it back. Take one idea, and put it back. If that idea tickles your fancy, then make it a subject for a deep read.

Ironically, reading deeply also does not require reading every word of every book. As you read topically you'll realize that there's overlapping content. Your first book on a subject may require special attention, but after that you can bound through a book in search of its unique angle.

You alone will have to make an accounting for how you spend your time, and you only have so much of it. Define your reading program based on your own goals and interests, then: Drop. Books. Ruthlessly. Even if it is one that you originally thought would be valuable.

By being ruthless, you will focus on the most potent ideas and build generous knowledge web. No one else will have your unique combination of ideas. Now you must write about them.

Writing

Software engineers undervalue writing. Probably this is so in any career. If you write well (emails, chats, texts, pull requests, documentation, ...), you will distinguish yourself. In addition to distinguishing yourself at work, in this internet age you can improve your chances of being discovered. You can write a niche blog and find an audience. You may not find thousands of readers, but you only need one reader to change your life with a job, a speaking engagement, an opportunity.

I could say a lot of things about writing well, but as I've read about it I've seen four themes: economy, action, warmth, reading.

Economy

Writers advise to avoid adverbs and adjectives, to remove qualifiers ("I think," "some," "many," "possibly"), to avoid cliches, to avoid fluff. Most of this advice reduces to using words economically. Say what you want to say briefly and clearly.

If some slip through, that's OK, because the editing process is 110% about removing words. Pascal famously said "I wish I could have written a shorter letter, but I did not have the time," because concision is hard. You will re-write, re-write, then re-write some more, and it should get shorter each time.

Action

I find this one really tough. As an engineer I usually describe machines and processes. I find it easy to write in a passive voice. (The last sentence was "It is easy for me to write in a passive voice.") When you write passively, you see state of being verbs. You end up with a pronoun as a subject, and the true subject later in the sentence. It's all a bit twisty for people to decode. You may find value in tools like writegood-mode for Emacs.

Warmth

William Zinsser's book On Writing Well is a worthwhile read. In it he advises writing with warmth, which for him is writing about the human element. He reminds me of the great preacher Charles Spurgeon who no matter the passage, Old Testament or New, he would find his way to Jesus. No matter the subject, William will always find his way to a story about people.

Writing about people is one way to achieve warmth. Another way is to write honestly with your own voice. Some people adopt an artificial voice when they write. Perhaps they sound too formal. Find your own voice and be true to it.

Reading

There are two ways that reading is important to writing well. First, reading what others have written will improve your language skills and inspire you. You'll develop an ear for good writing. Second, reading your own writing will help you re-write it. It should sound good to the ear but not in a flowery way, and it should sound like you.

Thoughts on the Death of Brook's Law

Brooks' Law is wrong.

Brooks' Law (the pithy version) is: "adding people to a late project makes it later." There is some truth to that, but it's more nuanced. A bad manager staffs up a late project (in an act of desperation?) to make a deadline. However, Bertrand Meyer (and Steve McConnell and Barry Boehm) believe—based on empirical evidence—that judiciously adding people to a project can shorten its schedule.

You can shorten a schedule by adding more people...however there's a limit. You can only shorten the schedule for a software project by (up to) 25%. Since adding people to a software project means adding cost, what this is really saying is you can spend more to get your thing up to 25% more quickly. However, the reverse is not necessarily true. Sometimes you can take people off a project, give the remaining people more time, and get your thing for less money; sometimes you cannot.

This has been known for about 20 years and yet Brooks' Law has survived as a folk wisdom, and Bertrand Meyer wants to get the word out. That's why he wrote "In Search of the Shortest Possible Schedule."

I grew up on Brooks' Law, so I'm trying to absorb this. Brooks' Law seems right to me, and in "Brooks' Law Repealed?" Steve McConnell describes an experience that seems familiar:

To those of us who have been around the software-project block a few times, the claim feels true. We’ve participated on projects in which new people are brought on at the end. We know the irritation of having to answer questions from new staff when we’re already feeling overwhelmed about our own work. We’ve seen new hires make mistakes that set the whole project back. And we’ve experienced additional schedule slips even after staff has been added to a late project.

McConnell squares this experience with the new sans Brooks' Law world by pointing out Brooks' Law does apply in certain circumstances, but projects are poorly estimated and poorly tracked. The result is not knowing whether you are in the Brooks' Zone or whether there is enough project left for new hires to pay off the productivity lost to training them.

I'm not sure I buy that. I think the idea of estimation is fundamentally flawed. I can't help but feel like this is saying, "We're doing a bad job. Do better!" I'm more and more convinced that breaking work down, estimating the pieces, and rolling it back up is a terrible way to estimate. It fails to account for variability, and padding estimates is not the solution.

And sure, better project tracking seems like a good thing. It is a necessary first step, but having the data isn't enough, you also have to interpret and extrapolate it. Probably the best thing that can be done with tracking data is to let it empirically drive estimations.

I cannot deny the empirical evidence. You can pay more to shorten a project by up to 25%, but there are some intriguing questions that pop up: Why? Why 25%? Why doesn't it always work backwards? Could you repeat the process with a revised schedule and cut another 25%? How would knowing about this bias estimations?

I think what I take away from this is that Brooks' Law has narrower application than I initially expected and adding people to a project can bring it to completion more quickly.

On Writing (Code)

Introspection into my own process for making software has led me to believe that writing prose and programming are fundamentally the same. This was further highlighted for me when I read Stephen King's On Writing. I saw interesting parallels between the way he likes to work and the way I like to work. Also my code is a horror story.

King likes to write a first draft as quickly as possible. He does this to get the story out. He doesn't worry about character development or even holes in the plot. Those he will fix up in the second draft. The first draft is about getting onto paper the good bones of a story. Then he lets the first draft sit for a couple of weeks.

When he can come back to the first drift and it looks familiar but not quite—like it was written by his doppelganger—then he has enough distance to make the second draft. That's where any story issues are fixed and things are smoothed out and tightened up. His goal is to make the story 10% shorter.

When I write code:

• I like to write code breadth-first so I can see all the moving parts and that everything fits together.
• I like to let it sit for a couple of minutes, or hours, or days—whatever I can afford.
• I like to smooth things out and tighten things up in the second draft—things like function names, refactoring, etc.

Maybe writing code isn't exactly like writing prose. Maybe it's more like knitting or woodworking or cycling or solving crimes. I think part of the reason that programmers tend to see their work in everything, is that programming is really just process for solving problems and giving form to thoughts. Those skills can be applied to many different domains. Maybe in that way it actually is more like writing than other hobbies?

At least I didn't say that programming is like gardening. I actually appreciate gardening as a hobby because of the fact that it is entirely different than making software!

How to Survive Life Undamaged

How does one survive life undamaged? Seriously... if you figure it out let me know. I particularly mean self-inflicted damage. You can't guarantee anything about how other people act or think.

Here is what I have tried (am trying):

1. Be willing to listen to others.

You don't have to listen to everyone, but be aware that you risk losing valuable perspective and insight, even if it is insight about how not to do things. You should probably be willing to listen to some people that you have shut out. If you are not uncomfortable, then you are not growing.

Everyone has a story. You can either imagine a person's story, categorize and label them, and treat them as if that story is true, or you can actually listen. You can listen to what someone believes while thinking about why they're wrong and how you will show them, or you can try to inhabit their space and see the world the way they see it. You don't have to stay there, but you will take lessons from it.

2. Be skeptical by default.

To listen to others and inhabit their space does not mean uncritically accepting their ideas. You can be empathetic, you can entertain an idea, without being swept away. You can also question if a person is wrong without imagining they are your enemy.

If some idea pushes through your skepticism, accept it. It is OK to move a little closer towards an "opposite" view.

3. Don't try to convince everyone.

This can be particularly painful when it is someone you respect and/or love. It may take time. Or it may never be. Life is sour sometimes. Don't make it more sour than it needs to be.

If you are skeptical by default, then maybe others are as well? If you are listening to others and inhabiting their space, then you must know that it will not be easy to convince everyone. You can let that bother you. You can turn it into an obsession, or you can focus on the good (what little you estimate there to be) and seek friendship.

These are three things you can try. If you refuse to listen to others and make it your life goal to convince everyone how they're wrong. You will have a life filled with stress and bitterness. Or you could listen--critically--and seek friendship over rightness.

Beyond Techniques

I firmly believe that writing software is a creative act. I believe that a construction project---or any other linerally presenting process---is the wrong analogy for software development. A much better one is writing prose, which is a process of writing and rewriting and rewriting, and sometimes throwing it all out and starting over. In the same way a software engineer names and renames, factors and refactors, etc., then extends the functionality by doing it all again. This all has to fit into the larger code base in a way that makes for a consistent whole. This requires judgement and taste.

To come at the argument from the other side, if you spent your days rewriting the same code over and over, then you would split it into more generic functions and perhaps a library. If you're solving the same problem that someone else has solved, then you would just reuse their software. This does in fact happen, and yet software engineers still get paid to work, and the value they generate is in the new stuff that requires creativity. Sure, there are some inefficiencies that mean people rewrite software that they could have just reused, and you could argue that the new things to be done are increasingly marginal, but on the whole software engineers would be out of work if there were not new things to create. Ergo writing software is a creative act.

The next reasonable question is: how does one create? I believe that fundamentally, and on average, one cannot directly induce creativity. This isn't entirely satisfying. I wish creativity was a predictable, mechanical process. Is it possible to discover and categorize tools for thinking? I'm still exploring that. Here's an example: to get a fresh perspective on your problem think not about how to solve it, but how to avoid failing to solve it. Instead of trying to figure out how to build a stronger bridge, maybe you'll gain insight by considering how to avoid building a weaker bridge. This technique for finding fresh perspective...does it not make creating into a predictable, mechanical process?

I actually like techniques. I believe the learning process is (or is best) technique based. Think about learning to cook. You start by following the recipe. Then you start to improvise. You understand that this ingredient is for flavor and can be adjusted to taste, but that ingredient provides aeration and messing with it too much will produce a dense, inedible result. Eventually you move beyond techniques and start to construct your own recipes from first principles. A poor education either starts with first principles, which a beginner does not have the experience to appreciate, or focuses too much on techniques divorced from context, which frustrates learners because they don't know how to properly apply techniques. I intended my book Clojure Polymorphism to position itself as a way to explore varied applications of the same tools and techniques, which I hope will guide readers from knowledge into wisdom.

The writing curriculum we use in homeschooling our children is technique based. A child reads an essay and creates an outline of the important points (there's a whole set of techniques for that). Then he will rewrite the essay from the outline applying techniques like "ly"-words, openers, and clinchers. This removes the hand wringing about what to write about. (Incidentally, if you read Ben Franklin's autobiography, this is the way he improved his own writing.) What if computer programming was taught this way? Here's a program that consumes a CSV file, changes some things, then writes it back out. First write out a high level algorithm for the program, then rewrite it using 3 of the 15 techniques you've learned (concurrency, multimethods, asynchronous channels, etc.). Repeat. I think this would produce wiser programmers.

However, eventually you need to move beyond techniques. Leaning on techniques is just shifting the problem elsewhere. Coining techniques is an attempt at mechanizing creativity, but instead of making creating mechanical, you are now faced with choosing which technique to apply to generate a creative solution. Now the creative leap must occur earlier in the process. You can try each technique in a brute force search, but I doubt many (if any) would consider that "creative," nor is it particularly efficient. The experience of repeatedly applying techniques should help you develop judgement and taste, so when you're faced with inventing from first principles, you have some gut sense or guiding aesthetic. That guiding aesthetic is not some set of rules for when to apply which techniques. If it were, then it would become a "library," so to speak. Anybody---or any machine--could evaluate the rules and perform the steps.

Techniques are great for broadening your learning, but they are not self applying. Learning all the techniques does not help you invent new techniques, nor will it induce creativity. You can know how to cut impeccable dovetails and square up lumber and drill straight holes, but that does not mean you will create beautiful furniture.

How does one develop this guiding aesthetic? You read a lot of other people's code. You write a lot of code. You read a lot of books. You work hard. Sorry, that's the best I've got. This is a continuing journey...to be continued.

However you do it, the end goal should be to move beyond techniques.

Virtual Machine Oriented Development

Most computing devices that we have today---desktop, laptop or phone---are capable of computing any program that can be computed. There's a bit of equivocation there. What is meant is that anything that a human can manually calculate via rote, mechanical process can also be done by computer. This is the Church-Turing Thesis.

I've never really stopped to think, but what would a non-universal computing machine look like?

....

Longevity

Several years back I suffered a bout of jealousy. I thought about engineers in other fields who build roads or buildings or even cars. A civil engineer can imagine something they've build standing still amidst the blur of 100 years passing by. An automotive engineer can imagine a car they've designed still driving the roads in 20 years.

I don't think a single line of code that I wrote 3 or more years ago is still in production, and that's ignoring all the code that I wrote that never made it into production.

These are the kinds of things you start to ponder as you reach the ripe, old, programmer retirement age of 33.

But then a funny thing happened. I played Sam & Max Hit the Road ... on my Android phone.

Here was a game released in 1995 and I was playing it on my Android device in 2014. How did that happen? Well, when LucasArts designed the game "Maniac Mansion," they decided to create a scripting language and write the game in that language, and they used that scripting language for many of the games they made. I have several original LucasArts games on CD. Some are PC versions some are Mac versions.

Over the years as I feel the nostalgia hitting me I'll grab the game files from the CD and download ScummVM for whatever platform I'm on at the time. I copied the game files to my phone and downloaded ScummVM from the Play store. That's how it happened.

....

Data is Code

I had been exposed to Lisp, and even written a lot of Lisp before I finally had my enlightenment about macros and metacircular interpreters. I remember vividly reading Structure and Interpretation of Computer Programs and seeing Scheme put to use creating simple yet powerful abstract interpreters. The author's start "simply" with interpreters that add new programming paradigms to Scheme. Then they proceed to simulating a register machine and writing an assembler and compiler for it. This happens in the last chapter, a space of ~100 pages.

It is a Divine joke that Structure and Interpretation of Computer Programs and The Art of Computer Programming had their titles swapped, because---while I don't wish to denigrate TAOCP which is a depth of amazing riches---SICP is about art, and in a metacircular way it is art.

It is too easy as a Lisper to understand the world this way, but data is always code. In Forth, 5 is not a number, it is an instruction to push the value 5 onto the top of the program stack. Your program receives a program as input. It receives files, network packets, key presses, and mouse clicks. It interprets this program and produces output.

A PDF file can cause a buffer overrun in a PDF reader because each byte is literally an instruction to your program-as-interpreter to "write a value at the current location and move to the next location" (or at least it can be if your program-as-interpreter has flawed semantics).

This is not a property of Lisp, it is a property of the stored program computer, Universal Turing Machine, von Neumann architecture. Code and data are made of the same stuff and stored in the same memory.

....

The Non-Divine Joke

In his talk "The Birth & Death of JavaScript," the 2014 version of Gary Bernhardt extrapolates where JavaScript and asm.js will take the world in 2035 (after an apocalyptic global war, of course). The punch line is that instead of JavaScript running on computers, computers run on JavaScript. This happens through a comical stack of emulators emulating emulators that emulate. Actually I think it's compilers transpiling compilers that transpile transpilers, but...same difference.

But like every joke there's a bit of truth to it.

Paul Graham writes about "Programming Bottom-Up" where you build the language "up" to your program to the point that actually expressing your program becomes somewhat trivial. You're building a domain specific language to solve exactly the problem you have. Again, this is all too natural for Lispers, but everyone does it.

The act of programming is to turn a universal computing machine into a limited computing machine. You build out data types and operations to focus the abilities of the computer into a specific domain. Programmers instinctively understand this, which is why we find it so funny that---in a twist of irony---a universal computing machine emulates a universal computing machine emulating a universal computing machine.

....

Virtual Machine Oriented Development

I started thinking about Virtual Machine Oriented Development because I was concerned about the transience of my legacy. I noticed that there were software products that were still around 20 years after they were written. I started seeing a VM underneath them.

But having thought about it more, I don't think that Virtual Machine Oriented Development is just about legacy. I think it might clarify the design process to be explicit about the fact that we're designing a limited computing machine that analyzes sales data. What are the data types? What are the operations? If you have power users, maybe they'd even like a scripting language that can describe which data to import and then how to analyze it?

You might find then that you've abstracted your problem into a computation model that will become valuable for years. Maybe you'll end up rewriting the interpreter for this language several times, and all the while users can keep using their existing scripts.

....

Conclusion

What does a non-universal computing machine look like? It looks like every program you've ever written.

Speed Reading

My reading habits are lumpy. I find I'm either not reading anything, or I'm reading seven books at once, and when I am, I wish I could speed read. I have in the past read books on speed reading, and they usually boil down to techniques like increasing your eye span, eliminating regression, eliminating subvocalization, etc. The theory seems to be that your brain can work much faster than your eyes, and you just need to eliminate bad habits, and establish some better ones, so you can get the words into your brain faster.

I do feel like there's something to this. In my experience, my mind tends to wander as I'm reading, and sometimes it's easier to skim since that keeps my mind busier trying to assemble random bits and pieces into a comprehensive whole. That seems to be the idea with this new speed reading book that I picked up called "Speed Reading With The Right Brain." The author claims that by engaging your brain in conceptualizing what you're reading as you're reading, you increase comprehension, and it is through increased speed of comprehension that you achieve increased reading speed. I want to believe, but I'm still skeptical.

What I would love is some reference that approaches speed reading from an empirical approach, you know, with science. What do we know that actually works based on research? Well...you may not like the answer.

Speed Reading is Fake

In looking for an empirically backed approach to speed reading, I came across "So Much to Read, So Little Time: How Do We Read, and Can Speed Reading Help?" This article is based on decades of reading research and cognitive psychology. One of the authors—who passed away from cancer a few days after the first draft—proposed the article "because he felt that it was important to share the knowledge we have gained from experimental science with the general public."

While there may be savants who can read impossibly fast without sacrificing comprehension, controlled studies show that for normal people learning to read faster means comprehending less. When you learn to "speed read" you are actually learning to skim. "Taylor notes that [Evelyn] Wood 'repeatedly stated that her people are not skimming, but rather are reading' (Taylor, 1962, p. 65). Based on recordings of their eye movements, however, Taylor concluded that they closely resembled the eye movement patterns produced during skimming (Taylor, 1965; see also Walton, 1957)." Also from the article:

The speed readers did better than skimmers on general comprehension questions about the gist of the passages but not quite as well as people reading at normal speed. … The advantage of trained speed readers over skimmers with respect to general comprehension of the text was ascribed by Just and colleagues to an improvement in what they called extended inferencing. Essentially, the speed readers had increased their ability to construct reasonably accurate inferences about text content on the basis of partial information and their preexisting knowledge. In fact, when the three groups of participants were given more technical texts (taken from Scientific American), for which background knowledge would be very sparse, the speed readers no longer showed an advantage over the skimmers, even on general questions.

According to the article, learning to speed read may improve your ability to skim, but only for familiar subjects. This isn't necessarily bad news for two reasons:

1. You can improve your reading speed, just not as dramatically as speed reading advocates suggest.
2. Learning to skim effectively is a useful skill to learn.

Improve Your Reading Speed

The average person reads between 200-400 words per minute. What is the best way to improve your reading speed? Practice. Unsurprising. Perhaps a little disappointing? There are a couple ways that practice increases your reading speed, but they basically break down to improving your language skills:

• better vocabulary
• exposure to more writing styles

The broader your vocabulary, the more familiar you are with words and styles, the more quickly you can read. Your eyes fixate less on words with which you are familiar, so they move more briskly across the page. Your familiarity with style allows you to anticipate better how a sentence will end when you've only read part of it. Also, "written language uses some vocabulary and syntactic structures that are not commonly found in speech, and practice with reading can give people practice with these."

The more you do reading, the faster you'll get.[1]

Learn to Skim Effectively

Effective skimming is mostly about trying to extract structure and important ideas from a text. Scan for:

• headings
• paragraph structure
• key words

According to the article, "Research has shown that readers who pay more attention to headings write the most accurate text summaries (Hyönä, Lorch, & Kaakinen, 2002)."[2] You can also do things like:

• scan the table of contents
• read the first paragraph of each section
• read the first sentence of each paragraph

Again from the article:

The eye movements revealed that skimmers tended to spend more time reading earlier paragraphs and earlier pages, suggesting that they used the initial parts of the text to obtain the general topic of passages and provide context for the later parts that they skimmed in a more cursory way. Therefore, effective skimming means making sensible decisions about which parts of a text to select for more careful reading when faced with time pressure. In fact, Wilkinson, Reader, and Payne (2012) found that, when forced to skim, readers tended to select texts that were less demanding, presumably because they would be able to derive more information from such texts when skimming. This kind of information foraging is a useful method of handling large amounts of text in a timely manner.

You know what else helps you skim effectively? Practice. Practice gives you a broader base of knowledge and experience to draw on:

That [knowledge/experience] may be the basis for some anecdotes about the speed-reading abilities of famous people, such as that President Kennedy could pick up a copy of the Washington Post or the New York Times and read it from front to back in a few minutes. However, consider the knowledge and information that someone like Kennedy would bring to the task of reading the newspaper. As president, he was briefed about important world events each day and was involved in generating much of the policy and events reported in the newspaper; thus, he probably had first-hand knowledge of much of what was described. In contrast, the average person would come to such a situation with very few facts at his or her disposal and would probably have to read an article rather carefully in order to completely understand it. To read rapidly, you need to know enough about a topic to fit the new information immediately into what you already know and to make inferences.

Of course, the downside of skimming is that you are skipping over portions of text resulting in lower comprehension. However, if you're looking to get a general overview or find one specific fact, then it can be useful. It may also be good for a first pass at a text before reading in depth.

Conclusion

I do feel as though my mind wanders when I read, and I wonder whether there is a way to better engage my mind when reading. Perhaps conceptualizing or visualizing or some other way of focusing more would help comprehension and speed. If and until I and figure that out, I can improve my reading speed by practicing and getting better at skimming, when skimming makes sense.

Footnotes:
[1] I wonder (off-the-cuff, anecdotally, non-scientifically) whether writing more also improves reading, for the same reason: it improves language skills.

[2] Interestingly, this means that as an author you bear some of the burden for helping readers quickly consume your writing. I had started to shy away from listicle style blog posts, thinking I'd try to contribute to a more high minded discourse that rewarded effort in reading and comprehending. This article has more headings and lists...maybe I'll do a little of both. :)